/mcp (promoted from settings in Phase 7). It surfaces the platform’s Model Context Protocol server so you can see exactly what your LLM clients are exposed to.
Layout
A header strip with live counts (“42 Tools / 7 Resources / 3 Prompts”) followed by a three-tab body:| Tab | Contents |
|---|---|
| Tools | Every MCP tool the platform exposes — name, description, and the first few input-schema fields |
| Resources | URI-addressable resources (run bundles, ledger exports, intervention payloads) |
| Prompts | Server-managed prompt templates that LLM clients can fetch |
Tools tab
Each tool card shows:- Name (
mcp_tool_name) — what the LLM calls - Description — server-supplied summary
- Input schema — first three required fields, with overflow indicator (
+5 more)
Resources tab
Resources are URI-addressed read-only payloads — typically run bundles (runs/{run_id}), ledger snapshots, and intervention details. Useful for inspecting what an LLM client can pull without executing a tool.
Prompts tab
Server-managed prompts the LLM can request by name. Authoring lives in the platform; this tab is read-only.Why a top-level route?
Phase 7 promoted MCP from a settings sub-page to a top-level entry to match how teams actually use it: MCP discovery is part of debugging an agent, not a configuration task. The new sidebar lists/mcp next to /runs and /ledger so it’s reachable in one click during incident triage.
Underlying API
The page reads from the MCP HTTP gateway:GET /mcp/toolsGET /mcp/resourcesGET /mcp/prompts
See also
- Platform → MCP — protocol reference and authentication
- SDK → MCP — calling MCP tools from a Python client
