The names, shapes and availability below are fixed. No MCP server serves them yet — this page publishes the contract ahead of the build.
Resources
The two definition resources return the model, never a customer’s numbers. The account resource returns one customer’s numbers and nothing about the model.
beacon://account/{account_ref}/intelligence
account_ref is an account identifier Beacon already holds. It is not a company name, not a domain, and not a search term. An identifier Beacon has never billed returns no_grain.
The values, their types and their availability are the account object. Every value on that object is available on MCP tools under a grant that covers it, including the recurring-revenue and retention values that are off by default for your CRM. Every read of a money value is recorded in the access log.
Two values on the account object describe the account’s data rather than its business — data_confidence and data_suppressed. Read them first. A health_score of 72 on an account whose data_confidence is 58 is not a score.
One limit is not a default and cannot be switched on: per-person product activity is aggregated inside Beacon and never leaves at that level of detail, on this resource or any other.
beacon://fit-definition
Returns the model behindfit_score, so a system holding data Beacon does not hold can apply the same judgement to it.
Dimensions. Five, fixed: icp_fit, product_fit, risk_fit, profitability_fit, growth_fit.
Weight profiles. Four, each summing to 1.00. Which one your instance runs is your configuration, and it is returned only to a grant that covers configuration.
Segment adjustments. Applied after the weighted sum. Enterprise: risk +0.03, growth −0.03. SMB: product +0.03, profitability −0.03. Each pair nets to zero, so the profile still sums to 1.00.
Tiers.
high_fit at 75 and above · medium_fit from 45 to below 75 · low_fit below 45.
Completeness floors. Below 30% of inputs present, the score carries a low-confidence flag and is not used for pipeline or retention decisions. Below 70%, it is used with its completeness stated. At 70% and above it is used in full. An input that is not yet available contributes a neutral value; it never drags the score down.
Order of composition. Weighted sum, then the data-confidence multiplier where confidence is below 80, then the segment adjustment. The multiplier lowers a score and never raises one.
Applying the balanced profile to an enterprise account scoring ICP 80, product 70, risk 60, profitability 65, growth 55 gives 17.6 + 14.0 + 13.2 + 13.0 + 8.8 = 66.6, and a tier of medium_fit. A system that reproduces 66.6 has applied the model correctly.
The response does not include the component register behind the five dimensions. Changing a weight profile requires joint approval inside your company and cannot be done through this server.
beacon://segment-definition
Returns the model that forms your segments, not the segments themselves.
Health tiers.
growing at 75 and above and improving · healthy at 75 and above and stable · developing 55 to 74 · declining 45 to 54 · at_risk below 45.
Bounds a segment set is formed within. Between three and twelve segments. Each holds at least ten active accounts or at least 5% of recurring revenue.
Your own segment names are your configuration and are not returned here. They reach a reader on the account object, per account, under a grant whose customer scope covers that account.
What travels with every value
A value is never returned as a bare number. Every response carries the following alongside it.
Every published definition carries a version of its own, counted from 1 and never reused. It moves whenever that definition changes — the wording, the shape, the bands, or which figure it names — so two numbers citing the same definition at the same version were produced against the same published definition, and a version you have already read is one you can rely on. Superseded versions stay readable, so a figure you stored last year can still be checked against the definition it was produced under.
A definition version is not the version of the published contract, and neither is a version of a model inside Beacon. A score produced by a model carries that model’s version separately, alongside its as-of.
A money value is converted before it leaves, on a fixed past date. Beacon uses the rate on the date of the billing event behind the figure, carried forward until the next one; for a contract that has taken effect but not yet been invoiced, the rate on its effective date; for figures ahead, the rate fixed at the start of the fiscal year. A rate for today is not used at any point. A receiving system that converts the figure again with a current rate breaks the guarantee that the same question returns the same answer.
Refusals
When Beacon cannot serve a value it returns a named refusal and what would make the value available. A refusal is a successful response carrying a reason, not an error and not an empty result.
A refusal is whole. A request outside a grant is refused and recorded, never partly served. Where a value is inside the grant but one property of it is switched off, that property is returned named and marked with its reason rather than dropped, so a withheld value and a missing value never look the same.
What connects, and what it reads
A connecting system presents a key Beacon issued. Beacon never holds your passwords to anything. That key resolves to one grant, and a grant names one person. Everything served under it sits inside that person’s own access — never wider, and never at the access of whoever set the connection up. A system several people use holds one grant per person and presents the key belonging to the person asking. Nothing leaks. What a grant states, and how to issue or revoke one, is on Access and grants. What a connection can see is settled when it connects, not when it asks. Anything the grant does not reach is absent from the list of resources that connection is offered — not present and refused. Narrowing or revoking a grant ends the connection rather than leaving a resource listed that has stopped answering.What this server will not do
No request Beacon serves through this server changes anything in Beacon or in your systems. No write of any kind. This server reads. Beacon writes back to your CRM through a separate path, where every write is a draft a person approves. Nothing here can be turned into a write. No open query. Every request names something Beacon already publishes, at a version. There is no query language and no expression field, and the list of resources grows by published additions rather than by accepting a query. Nothing worked out on request. Beacon serves what it has already computed exactly and, where the figure is sealed, already sealed. Ask twice, get the same answer twice — any reader, any hour. No score on a company Beacon has never billed. A company with no billing history has no lifecycle and no economics behind it. Beacon returnsno_grain and serves the fit model instead, so a system holding its own data about that company can apply the model to it.
No prompts. MCP’s third capability is prompt templates. Beacon publishes none. The interface between Beacon’s figures and a reasoning layer is specified for use inside Beacon and is not published for outside use.
No enforcement inside your tools. Beacon cannot control what a system does with a figure after it reads it. What Beacon does is attach the definition, the dates, the confidence and the currency anchor to the figure, so a system that reads it cannot claim it did not have them.