Overview
What the Subcore MCP server does, what it deliberately does not do, and how it is scoped.
The Subcore MCP server lets an AI client — Claude Desktop, Claude Code, or your own agent — talk to the agents you have deployed and read the telemetry they produce.
| Endpoint | https://api.subcore.ai/mcp |
| Transport | Streamable HTTP, stateless |
| Auth | Authorization: Bearer <Subcore API key> — the same key as the read API |
One URL, one key, no deployment secret in a config file anywhere. Start at setup.
What it is for
Running an agent as a brain. You send a customer's message to your deployed agent and get back what it would say — with the CRM lookup, persona and business facts that agent already has. You then decide what to do with the text.
Reading telemetry. The same sessions, events and evaluation runs the read API serves, as tools an AI client can call directly.
Testing an agent. Every conversation tool runs its turn through the
deployment's playground door, with that channel's real instructions and tools.
The turns are recorded as telemetry with run_type: "test", so they never mix
into your production numbers.
What it is not for
The MCP server never contacts a customer. Not by phone, not by SMS, not by email. It returns text; your own workflow decides whether anything is sent.
That boundary is enforced, not merely advised:
The cost-incurring doors have no tools. A deployment's POST /outbound
places a real phone call and POST /sms/send sends a real text, both on your
bill. Neither is ever turned into a tool. They are excluded by path, before any
other rule is considered, so a deployment cannot expose them by accident.
Vendor webhook doors have no tools. Form-encoded doors — the ones Twilio posts to — are excluded too. Twilio composes those bodies; a tool that wrote one would be a tool for forging a webhook.
Takeover is out of scope. Claiming a live conversation and replying to the customer on it is a real capability elsewhere in the platform, and it is deliberately not here. If it is ever offered over MCP it will be a separately named, separately enabled tool set — not something you get by turning on testing and telemetry.
How it is scoped
The API key is the tenant. It resolves to one organization, and the tool list is built from what that key can actually reach.
The tool list is generated per request, not maintained by hand. The server reads each reachable deployment's published manifest and derives a conversation tool for each of its JSON message doors. So the tools you see depend on which agents your key reaches and what those deployments publish — see tools.
permissions.cores narrows which agents appear, and
permissions.telemetry decides whether the telemetry tools appear at all.
Both work exactly as they do on the read API.