RevenuePilotby Foxes TechnologyEvery RevenuePilot workspace ships a read-only Model Context Protocol server, so your own AI agent can read the same numbers your team reads. It re-enforces the same policy, scope and tenant isolation as the application—there is no agent-specific bypass.
MCP is a standard way for an AI assistant to connect to a system and read from it through a defined set of tools, instead of scraping a screen or being handed a spreadsheet.
Any assistant that speaks the Model Context Protocol can be pointed at your workspace's server. RevenuePilot does not ask you to adopt a new assistant or build an integration by hand.
Access is granted by an inbound key that belongs to one organization. The key is stored hashed, and it carries the scope it was issued with—nothing broader.
Six read-only tools, described in the protocol so the agent knows what each one returns. There is no free-form query surface and no generic passthrough into the database.
A tool call runs the same policy, scope and tenant checks the application runs for a signed-in operator. A call outside the key's organization or scope is refused, not narrowed.
Reads land in the append-only audit trail with the key identity as the actor, so an agent's activity is reviewable in the same place as everything else.
The list is deliberately short. Each tool answers a question an operator or an agent actually has, and each returns the reconciled view rather than raw rows.
| Tool | What it returns | Why it matters |
|---|---|---|
| portfolio_kpis | Margin, revenue and occupancy | The operating picture, without exporting to a spreadsheet first |
| revenue_calendar | Departures, capacity and price | Departure-level state an agent can reason about by date |
| pricing_recommendations | Advisory recommendations, with evidence | The ranked queue and the receipt behind each move |
| qualification_posture | Shadow and canary progress | How far a workspace is along the automation ladder |
| audit_events | The append-only decision trail | Who decided what, when, and under which boundary |
| connector_health | Source freshness and status | Whether the numbers behind an answer are current |
The agent surface is not a second authority. UI, API and MCP share the same tenant and policy authorization boundary, while MCP remains read-only and never enters the governed execution path.
Every MCP tool re-enforces the same policy, scope and tenant isolation as the application. There is no agent-specific bypass and no second money path—if a route is closed to an operator in the interface, it is closed to an agent for the same reason, checked in the same place.
The agent surface is built on the same organization-scoped hashed inbound-key layer the Generic API uses—one key layer, one set of semantics. The audit actor for anything an agent reads is the key identity, so activity is attributable to the credential rather than to an anonymous integration.
An agent discovers exactly the six tools that exist. Nothing is advertised that the surface cannot do, and there is no undocumented tool, escape hatch or generic query endpoint behind the published list.
Being explicit about the ceiling is what makes the surface usable in a revenue system.
| Action | Available to an agent |
|---|---|
| Read portfolio KPIs, calendar and recommendations | Yes |
| Read evidence, audit events and connector health | Yes |
| Read qualification posture | Yes |
| Read another organization's data | No — refused by tenant scope |
| Change a price or apply a recommendation | No — no execution route exists |
| Change policy, guardrails or automation level | No |
The absence of write tools is a design decision, not a gap in the roadmap we have not reached.
Write or execution tools over MCP are not available. They would only ever be considered after a tenant clears the same shadow and canary ladder that governs the interface, and they would carry identical interlocks—there is no version of this where an agent gets a shorter path than a person.
The deterministic guardrails are properties of the execution plane, not of the calling surface: minimum confidence 85, maximum movement 5%, cooldown 24 hours, floors and ceilings, read-back verification and version-fenced rollback. A caller cannot loosen them by being an agent.
High-impact actions require TOTP step-up by design. That requirement is what an execution-capable agent would have to sit behind, which is precisely why read-only is the honest shape of the surface today.
No. The agent surface has zero execution routes. All six tools are read-only, and there is no write, price or policy tool published or hidden behind the published list.
No. Every tool re-enforces the same policy, scope and tenant isolation as the application. UI, API and MCP share one authorization path, so an agent's visibility is bounded by the key's organization and scope.
Through the same organization-scoped hashed inbound-key layer the Generic API uses. Keys belong to one organization, are stored hashed, and the audit actor for anything read through them is the key identity.
They are not available today. They would only be considered after a tenant clears the same shadow and canary ladder the interface requires, with identical interlocks and the same step-up requirements—never as an agent-specific shortcut.
Connect a Model Context Protocol client to a scoped, hashed, fully audited read-only surface. Nothing it touches can move a price.