Skip to content
Live

MCP

Both ends of the protocol: server and client.

What it does

The platform is an MCP server: an OAuth 2.1 resource server with scope checks, an approval policy and a call ledger. This allows external clients to use your agents as tools. It is also an MCP client: any remote MCP server becomes a connector without per-provider code, guarded by a circuit breaker so a flaky third party cannot take a conversation down with it.

Why it matters

Most products pick one end of MCP and call it support. Being both means your agent can be used as a tool and can use tools, which is what makes it composable rather than terminal.

How it works

  • Server side is a real OAuth 2.1 resource server

    Scope checks and an approval policy gate tool calls, and calls are written to a session ledger rather than being fire-and-forget.

  • Client side is generic

    Adding a remote MCP server is configuration. Only a couple of connectors have hand-written native adapters; the rest go through the generic path.

  • A failing tool server is contained

    A circuit breaker trips on a misbehaving remote so its failures degrade one capability instead of the conversation.

Questions

Can I plug in my own MCP server?
Yes: it becomes a connector with no bespoke code. Authentication is a static bearer token today; OAuth 2.1 for custom remote servers is planned.
Can other tools call my agent over MCP?
Yes. The platform exposes an MCP server surface with OAuth, scopes and an approval policy.
Back to the story

That was step 5 of 6: the agent consults its bag. Next, tasks, delegation edges, decisions and artifacts persist as rows you can replay, and the spend is already accounted for.