> ## Documentation Index > Fetch the complete documentation index at: https://docs.beaconrevenue.io/llms.txt > Use this file to discover all available pages before exploring further. # MCP tools > The resources Beacon's MCP server publishes, what travels with every value, the five refusals it returns, and what it will never do. Beacon's MCP server publishes three resources, no tools and no prompts. Every resource is read-only, every response carries the context needed to check the value in it, and a request Beacon cannot serve returns a named refusal rather than a null. The names, shapes and availability below are fixed. No MCP server serves them yet — this page publishes the contract ahead of the build. ## Resources | Resource | Returns | Scope required | | --------------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | `beacon://account/{account_ref}/intelligence` | The seventeen values Beacon publishes on one account, plus the two timestamps that travel with them | A grant covering the account family, whose customer scope contains `account_ref` | | `beacon://fit-definition` | The fit model — five dimensions, four weight profiles, three tiers, two completeness floors | A grant covering the fit family. No customer scope; there is no account in the response | | `beacon://segment-definition` | The segment model — six weighted dimensions, five health tiers, the bounds a segment set is formed within | A grant covering the segment family. No customer scope | 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](/data-model/account). 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 behind `fit_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. | Profile | ICP | Product | Risk | Profitability | Growth | | ------------------- | ---- | ------- | ---- | ------------- | ------ | | `balanced` | 0.22 | 0.20 | 0.22 | 0.20 | 0.16 | | `growth_aggressive` | 0.20 | 0.22 | 0.18 | 0.16 | 0.24 | | `retention_first` | 0.20 | 0.20 | 0.30 | 0.20 | 0.10 | | `margin_optimised` | 0.22 | 0.18 | 0.20 | 0.28 | 0.12 | **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. | Dimension | Weight | | -------------------------- | ------ | | Lifecycle economics | 0.28 | | Product adoption behaviour | 0.22 | | Commercial motion | 0.18 | | Firmographic structure | 0.15 | | Customer quality | 0.10 | | Signal health | 0.07 | **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. | Field | Holds | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | `definition_id` | Which published definition the value instantiates | | `definition_version` | Which version of that definition. Counted per definition, and it moves whenever the definition changes | | `as_of` | The moment the value describes. For a value composed from several sources, the oldest of them, unless the value names an anchor source and says so | | `computed_at` | When Beacon last worked the value out | | `freshness` | The value's age, and whether it is inside the freshness limit the grant sets | | `sealed_or_live` | Whether the figure is sealed, and if so its seal reference | | `confidence` | The published value that states how sound this one is. On the account object that is `data_confidence` | | `source_state_ref` | The state of each connected system the value was built from | | `transform_version` | The pinned version of the preparation step behind the value. Present on sealed figures | | `currency_anchor` | Money values only. The reporting currency, the billing currency, the date whose rate was used, and which kind of anchor that date is | 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. | Reason | Means | | -------------------- | -------------------------------------------------------------------------------------------- | | `not_computed` | Beacon has not produced that figure. It will not invent one | | `not_activated` | A connected system this value needs is not switched on. The response names which | | `outside_grant` | The request falls outside what the grant allows. The response names which part | | `stale_beyond_floor` | The newest value is older than the grant permits. The response carries its age and the limit | | `no_grain` | Beacon has never billed this company, so it has nothing to say about it | 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](/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 returns `no_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. ## Versioning The published contract is versioned separately from Beacon's internal model. A resource name is permanent; a rename ships as a redirect. A field is never removed from a published version — it is deprecated, and the removal lands in the next version. This page covers the account object. Beacon publishes values at other levels — deals, segments, periods and plan figures — and each reaches this server as its shape is published.