MCP servers
The tool fabric in depth — what MCP is, how your agents reach the local servers, and one page per server, tool by tool.
MCP — the Model Context Protocol — is how an agent gets hands. A Claude session can reason on its own, but to do anything — search your memory store, walk your knowledge graph, harvest a feed, render a video, open a terminal — it calls a tool, and tools are served by MCP servers: small local programs that expose a typed set of operations. The session launches each server as a child process on your machine and talks to it directly; there is no network hop between the agent and a server, and no hosted component anywhere in the fabric.
Why every substrate has an agent door
That is the product promise this section documents: the tool surface is deliberately open, because the point of the platform is that your agents work — with your memory, your knowledge graph, your intelligence desk, your creation pipelines, and the running app itself. All 17 servers ship wired and ready — 290 tools in this release — and every agent session gets the same surface:
- Your main working session launches the servers directly from the generated server configuration at the install root.
- Grounded terminal sessions and scheduled routine runs reach the same servers through one shared local gateway instead of each spawning a private copy — fewer processes, identical tools. If the gateway is down, sessions fall back to launching servers directly; nothing is stranded.
Most servers hold no logic of their own: they are thin, credential-free fronts over the local daemons that do the actual work. That split is deliberate — mechanical work lives in a service you can restart and monitor, and the server stays a stable doorway. It is also why a tool can return a "daemon unreachable" result while the server itself is healthy: start the daemon at Dashboard ▸ Platform Health and the tool works again.
The server map
Knowledge & memory
| Server | Tools | What it fronts |
|---|---|---|
| shared-agent-memory | 7 | The fleet's shared long-term memory — a local hybrid-search store every agent reads and writes |
| knowledge-base | 22 | Knowledge-graph ingest and lifecycle — workspaces, depths, enrichment, root sync — via the knowledge-base daemon |
| arcadedb | 12 | The graph query arm — direct read, traversal, and editing of the knowledge graph |
Intelligence & harvesting
| Server | Tools | What it fronts |
|---|---|---|
| observer | 23 | The harvesting desk — sources, batches, schedules, harvest runs, and the item pool |
| gemini-direct | 1 | A second model on demand, with visible token usage |
| x-grok | 6 | The Voice provider surface — Grok chat, media generation, and live web and X search on your own account |
Creation verticals
| Server | Tools | What it fronts |
|---|---|---|
| imagegen | 8 | The local image-generation daemon — covers, hero images, section illustrations |
| remotion-mcp | 25 | The code-driven video engine — briefs, compositions, brand presets, renders |
| hyperframes-mcp | 19 | The HTML-first video engine — briefs, storyboards, site capture, render and lint |
| footage-mcp | 15 | Raw-recording preparation — transcribe, cut, grade, render a clean take |
| products-mcp | 26 | The knowledge-product pipeline — stages, dispatches, scope gates, export |
Platform control
| Server | Tools | What it fronts |
|---|---|---|
| cc-terminals | 31 | The terminal control plane — open, drive, and read visible terminal sessions; the mission-fleet verbs |
| cc-window-control | 28 | Windows, views, and the graph canvas of the running app |
| missions | 12 | The missions registry — create, transition, and audit missions and operations |
| calendar-mcp | 14 | The schedule — read it, author entries, and leave sketches for you to review |
Communication
| Server | Tools | What it fronts |
|---|---|---|
| 19 | Standard mailbox operations over IMAP and SMTP, with human-approved outbound | |
| x-mcp | 22 | The X drafting surface — agents draft, humans approve |
About the tool tables
Every server page below embeds its full tool table — name, description, and parameters, with required parameters marked. These tables are generated from the shipped tool definitions, not written by hand, and they regenerate with each release — what you read is what your install actually exposes. The tool counts in the map above come from that same generated layer, so they cannot fall out of step with the tables they summarise.
Wiring, health, and keys
The whole fabric is wired from one place: your settings file at the install root. A configuration-sync step generates the server wiring from it — you never hand-edit the generated file, and your secrets stay in the one file you own. The configuration reference covers every key; the MCP Servers view shows per-server health and what to check when something degrades.
Two facts worth carrying into the per-server pages:
- Local-first, your keys. Every service behind the fabric binds a loopback address on your machine, and every credential — model keys, mailbox passwords, account tokens — is one you supply. Nothing ships with a bundled key, and nothing phones home.
- Human gates are structural. Where a tool surface touches the outside world — email, social drafts, newsletters — the send action is a human decision in the app, not an agent tool. The per-server pages state exactly where those gates sit.
Agentic infrastructure
The working surface beneath the views — the tool fabric, the agent roster, skills, routines, memory, the knowledge graph, the daemons, and the doctrine that governs them.
shared-agent-memory
The fleet's shared long-term memory — persisting, searching, and curating what your agents learn.