MCP Servers

Every substrate an agent touches — shared memory, the knowledge graph, email, news harvesting, terminals, the video pipelines, missions — is exposed as an MCP server: a typed tool server a Claude session calls. The MCP Servers surface shows what is wired, whether each server is healthy, and the status of the shared gateway that fronts them.

Open it at Settings ▸ MCP Servers.

Read the surface

The header summarizes the fabric in one line: how many servers are online out of the total, read from the server configuration at the project root. The Refresh button re-runs all checks.

Below it, one card per configured server:

• Name and status — a plain-language label (hover shows the technical config key) and a status pill: healthy or degraded, with a matching status dot.
• Structural checks — each card lists the checks behind its status: the server's directory exists, its entry script is present, its Python interpreter resolves, and its data files (a database, a workspace folder) are where they should be. Each check shows ok / warn / error with a detail line.

A healthy card means the server is correctly installed and wired. That is deliberately a structural statement — see "Servers vs. daemons" below for the live half of the picture.

The gateway card

At the top of the list sits the MCP Gateway — a shared HTTP front (on local port 8772) for the whole server fleet. Its card shows online / degraded / offline and, when online, how many backend servers it is fronting.

Why it exists: grounded terminal sessions and scheduled routine runs connect to this one shared gateway instead of each spawning their own private copy of every server. Fewer processes, same tools — every server exposes identical tools whichever way a session reaches it. If the gateway is ever down, sessions fall back to spawning servers directly, so nothing is stranded.

The gateway's start/stop and autostart controls live with the rest of the daemon fleet at Dashboard ▸ Platform Health.

Servers vs. daemons

Several MCP servers are thin fronts over local service daemons — the routines scheduler, the knowledge-base service, image generation, the news harvester. For those, this view answers "is the server wired correctly?", while the daemon's live status (running, uptime, start/stop, autostart) lives at Dashboard ▸ Platform Health. A tool call can fail with a "daemon unreachable" result even when the server card here is healthy — that means the wiring is fine and the daemon behind it needs starting.

The full map of which server fronts which daemon is in the MCP reference and the daemons reference.

When a server degrades

Work down this list:

1. Refresh — the checks are point-in-time; re-run them first.
2. Read the failing check. A missing entry point or interpreter usually means an incomplete install or a moved folder; a missing data file often just means the server has not created it yet (first use creates most of them).
3. Check the daemon if the server fronts one — Dashboard ▸ Platform Health, start it or restart it there.
4. Regenerate the wiring if configuration has changed. The server configuration file is generated from your central settings — you never hand-edit it. Re-running configuration sync rewrites it consistently for every server at once; your secrets stay in the one settings file you own.

After adding or removing a server, restart the gateway so it picks up the new set, and reload your Claude session so the new tools register.

Where to go next

• The MCP reference — every server, tool by tool
• The daemons reference — the local services behind the fabric
• Terminals — the grounded sessions that reach these servers through the gateway