Which connection path to use

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. This page answers the question that comes before it.

​

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: 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. 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

​

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 · API reference · MCP tools · Boundaries