> ## 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. # Which connection path to use > Four ways to get Beacon's figures into the rest of your stack — the one question that decides between them, and what stays the same whichever you pick. Beacon holds one agreed set of figures for your company, and four paths carry them into everything else you run. This page is about choosing between them. What each path is, and what a grant states, is on [Access and grants](/access-and-grants). This page answers the question that comes before it. All four paths are designed and none is serving yet. The two read contracts are published so you can plan against fixed names and shapes before anything is built. What is enforced today is on [Boundaries](/boundaries). ## The question that decides it **Was the question written in advance, or is it chosen in the moment?** Someone wrote a query once, tested it, and a machine now repeats it on a schedule — that is the **read interface**. Nothing is deciding anything, and the same request needs the same shape back every time. A person asks something new and software has to work out what to fetch — that is **MCP tools**, the assistant connection. The question is different each time, and something has to choose. The other two paths are not asked at all. Beacon sends. ## The read interface For your own systems, running your own code, on your own schedule. * A BI dashboard that refreshes every morning * A warehouse sync * A planning model pulling last period's actuals * A board pack or an investor report assembled on a cadence * Another product showing a Beacon figure inside its own screen The contract is the [API reference](/api-reference): five collections, a fixed set of values, and a version of its own that moves only when the shape you read changes. ## MCP tools For people working through an assistant, and for software that reasons before it acts. * Someone asking how a segment performed last quarter and what moved * A sales assistant pulling account context before a call * An agent weighing whether an account is worth acting on this week The published set is on [MCP tools](/mcp-tools). One difference worth knowing before you choose. A key on this path resolves to a grant that names **one person**, and an assistant several people share holds one grant each, presenting the key of whoever is asking. So two colleagues can ask the same question and correctly get different answers, because they are allowed to see different things. If that matters for what you are building, it is the deciding factor rather than a detail. ## Events For being told, rather than asking. An account slips off plan, a target is missed, a period is sealed — Beacon sends, and your automations and alerting react. This is also how software that speaks neither of the two read paths stays current. If you would rather pull, the same ground is covered by an *events since* read. ## CRM property Beacon keeps a small, named set of values current on your own account and deal records, inside your own CRM, through that tool's API. This is the path most teams underrate. Nothing has to integrate with Beacon at all: every tool, report and workflow that already reads those records picks the values up, and most of the people who benefit never open Beacon. Beacon only ever writes values it created, never touches a field you authored, and every write is a draft a person approves. The trade is visibility. A figure written onto a record can be seen by everyone with a seat in that tool, and cannot be narrowed afterwards — which is why the revenue and retention values are off unless you switch them on. ## Choosing for an agent Agents land on either side, and the same question separates them. An agent running a fixed job with the same inputs every time is a system on a schedule: the read interface. An agent deciding what to do next, on a question nobody wrote down in advance: MCP tools. ## What does not change, whichever you pick | | | | - | - | | The figure | One stored set of values behind all four paths. Ask over two paths, get the same number and the same calculated-at stamp | | The ceiling | The path changes the transport and the audience, never what a reader is allowed to see | | What travels with it | The definition and its version, the two timestamps, freshness, whether it is sealed, confidence, and the currency anchor | | No open query | Every request names something Beacon already publishes. There is no query language and no expression field on any path | | No writes into Beacon | All four are read paths out. Nothing you send changes a figure | | Refusals | Where Beacon cannot serve something it says which of five reasons applies. Never a null, never a zero, never a quiet gap | ## Where this stands today The read interface and MCP tools are **published and not yet served** — the contracts are fixed, no key can be issued, and there is nothing to call. Events and CRM properties are specified and unbuilt. The practical consequence is a good one: you can design an integration now, against names and shapes that will not move under you, and the work will not be wasted. Related: [Access and grants](/access-and-grants) · [API reference](/api-reference) · [MCP tools](/mcp-tools) · [Boundaries](/boundaries) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.