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 session calls. 17 of them ship wired, exposing 288 tools on a default install. 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.

MCP Servers is a Pro surface — see Tiers: Pro & Ultra. Without an active subscription the tab renders a lock instead of the server grid. The servers themselves are ordinary Python packages under mcp-servers/ in your install root; the tab is the readout, not the fabric.

Read the surface

The header summarizes the fabric in one line: how many servers are online out of the total, read from .mcp.json at your install 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: one shared front means fewer processes than every session spawning its own private copy of every server, with no difference in what the tools do — a server exposes identical tools whichever way a session reaches it.

Two callers, two defaults, and they are not the same:

• Scheduled routine runs go through the gateway by default. The dispatch is health-gated: if the gateway is down or absent, that run silently falls back to spawning servers directly rather than failing.
• Agent terminal sessions spawn their own servers by default. Routing them through the gateway is a deliberate choice at Settings ▸ Daemons ▸ Main session MCP transport — Own servers (stdio) is the shipped setting, Shared gateway is the alternative, and the change applies to the next in-root terminal you launch (the pane shows an MCP·gw badge when it took effect). A session started outside Command Center always uses its own servers.

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. .mcp.json 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 session so the new tools register.

A refusal is not a degradation. If a tool call comes back refused while its server card is healthy, the cause is usually an agent control plane rather than the fabric — see Autonomy and controls.

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
• Autonomy and controls — which agent actions a switch can refuse