MCP Servers

The MCP Servers page manages remote MCP integrations.

It is also one of the clearest examples of the platform/runtime boundary. The platform owns server registration, OAuth posture, and role policy. The runtime later consumes the granted MCP surface when a task is claimed.

What Lives Here

remote MCP server registrations
connectivity verification and re-verification
discovered tool, resource, and prompt snapshots
shared OAuth client profiles and reconnect flows
the MCP surfaces operators can later link to specialists

Why It Matters

This page lets operators treat external tool surfaces as explicit policy objects instead of as hidden prompt assumptions.

Registering a remote MCP server does not automatically expose it to every agent. The normal flow is:

register and verify the server here
link or grant it to the right specialist on the Specialists, Skills, And Models page
let the runtime expose that server’s tools only when that specialist is actually executing a claimed task

That split matters. It keeps external tool access deliberate instead of turning every verified integration into a globally available prompt assumption.

Operator Use

Use this page when you need to:

register a new remote MCP endpoint
repair broken auth or connectivity
review the discovered capability surface before linking it to specialists

Relationship To Specialists

The Specialists, Skills, And Models page is where remote MCP servers become part of a specialist’s usable tool surface.

Think of this page as the inventory and trust boundary, and the specialist page as the assignment boundary:

here, you define what external MCP surfaces exist and whether they are healthy
there, you decide which specialists may use which MCP surfaces
during execution, the runtime loads only the MCP servers granted to the specialist that claimed the task