ThinkingRoot Docs
Integrations

MCP

How ThinkingRoot exposes your project over the Model Context Protocol.

Every project speaks MCP so AI tools can use it as a tool server. For the copy-paste setup per client, see Connect your AI tool; this page explains what's happening underneath.

What your AI gets

Once connected, the client sees ThinkingRoot's tools — ask, search, compile, branch operations — plus the tools of any connectors you've installed. Installing a connector live notifies connected clients via a tools/listChanged notification, so new tools show up without a reconnect.

Transport

The engine implements the 2024-11-05 dual-channel SSE MCP transport:

  • GET /mcp/sse opens a long-lived Server-Sent Events stream (server → client) and first emits an endpoint frame telling the client where to POST.
  • POST /mcp (with a sessionId) carries client → server JSON-RPC requests; the engine correlates each request with its response on the SSE stream via its mcp_sessions map.

The gateway in the middle

The engine's own MCP endpoint has no authentication — it's loopback-only and assumes a trusted caller. The gateway is that caller:

  1. It authenticates your inbound Authorization: Bearer tr_sk_… key and resolves which project's engine to talk to.
  2. It injects the engine's internal key and relays the stream.
  3. It rewrites the endpoint frame so the client posts back to the gateway (not the daemon directly), then relays those POSTs verbatim.

So your tr_sk_… key never reaches the engine, and the engine is never exposed to the internet.

Use the URL the Console gives you

Copy the MCP URL from the MCP & Agents tab rather than hand-constructing it — the gateway's MCP route is an internal contract that can change, and the Console always emits the form that matches your deployment.

Authentication

All MCP traffic authenticates with a project tr_sk_… key as a bearer token. Create one in the API Keys tab; revoke it there to cut off access instantly.