Facio's MCP Management: Dynamic Server Lifecycle Control From the Agent Itself

The Model Context Protocol (MCP) has become the standard way to give AI agents access to external tools — databases, APIs, browsers, file systems, and hundreds of specialized services. Most agent platforms support connecting MCP servers. Very few support managing them dynamically from the agent itself — toggling tools on and off, editing configurations, restarting after failures, and negotiating transport protocols.

Facio's manage_mcp tool puts the full server lifecycle into the agent's hands — with HITL gating on every destructive change. Here's how it works and why dynamic management matters more than static configuration in production.

Beyond Static Configuration

The typical MCP setup flow looks like this:

1. Human writes a server configuration (command, args, URL, headers).
2. Platform starts the server at agent boot.
3. The server runs until something breaks.
4. Human intervenes to fix it.

This works for development. It breaks down in production, where:

• A server goes offline at 3 AM and the agent can't recover.
• A server needs a temporary config change for a specific workflow.
• A new server should be added mid-session based on discovered needs.
• A misbehaving server should be disabled without restarting the entire agent.
• An HTTP server needs transport negotiation (Streamable HTTP vs. SSE fallback).

Facio's manage_mcp solves all of these by making server management a runtime tool — not a startup config file.

The Seven Operations

The tool surface is deliberately complete:

Action	What it does	HITL gating
list	Show all servers and their status	None
add	Register a new MCP server	Requires approval
remove	Delete a server permanently	Requires approval
edit	Update server config (transport, headers, timeout)	Requires approval
enable	Activate a server	None
disable	Deactivate a server	None
restart	Reconnect an existing server	None

The asymmetry is deliberate: non-destructive operations (list, enable, disable, restart) run immediately. Destructive operations (add, remove, edit) require human approval. The agent can maintain its own infrastructure without being able to silently reconfigure it.

Transport Negotiation: HTTP Without the Guesswork

One of the most practical features of manage_mcp is automatic HTTP transport negotiation. The MCP ecosystem uses two HTTP-based transports: Streamable HTTP (newer, more efficient) and SSE (Server-Sent Events, older, widely supported). Not every server supports both, and figuring out which one to use typically requires trial and error.

Facio handles this automatically. When adding a server with a URL and no explicit type:

{
  "url": "https://mcp.example.com/mcp",
  "headers": {"Authorization": "Bearer ${credentials.MCP_TOKEN}"}
}

The runtime first attempts Streamable HTTP. If the server doesn't support it, it falls back to SSE automatically. The agent doesn't need to know or care about the transport layer — it just provides the URL and headers.

When a server needs a specific transport (some older servers only support SSE), the type parameter forces the choice:

{
  "url": "https://legacy-mcp.example.com/sse",
  "type": "sse"
}

This matters in production because transport mismatches are one of the most common MCP failure modes — and the most frustrating to debug without tools.

Lifecycle Patterns That Matter in Production

Pattern 1: Graceful Degradation

An agent is running a multi-tool workflow. The weather MCP server goes down. Instead of failing the entire workflow, the agent:

1. Detects the failure from the server's response.
2. Calls manage_mcp(action="disable", name="weather-server") to stop retries.
3. Continues the workflow without weather data, noting the gap.
4. Logs the incident for human review.

No restart required. No configuration file to edit. The agent handled infrastructure failure as a runtime decision.

Pattern 2: Workflow-Specific Tooling

An agent starts a research task and realizes it needs web search capabilities beyond its current toolset. Instead of asking the human to edit a config file:

1. Agent calls ask_approval — "I need to add a Brave Search MCP server for this research task. Approve?"
2. Human approves.
3. Agent calls manage_mcp(action="add", name="brave-search", config=...).
4. Server connects. Agent uses it for the research task.
5. Agent calls manage_mcp(action="remove", name="brave-search") when done.

Tools become disposable. The agent's capability surface expands and contracts based on task needs — not a static startup config.

Pattern 3: Rolling Config Updates

A team updates the authentication method for their internal API. The old API key is deprecated; a new OAuth flow is in place. Instead of touching every agent's config file:

1. Operations sends a message: "Update the internal-api MCP server to use the new auth header."
2. Agent calls manage_mcp(action="edit", name="internal-api", updates={"headers": {"Authorization": "Bearer ${credentials.NEW_API_TOKEN}"}}).
3. Human approves the edit.
4. Agent calls manage_mcp(action="restart", name="internal-api").
5. Server reconnects with new credentials. Zero downtime.

Pattern 4: Stdio Server Management

Not all MCP servers are HTTP-based. Many run as local processes — Python scripts, Node.js tools, binary executables. manage_mcp handles stdio servers with the same API:

{
  "command": "npx",
  "args": ["-y", "@anthropic/mcp-server-github"],
  "env": {"GITHUB_TOKEN": "${credentials.GITHUB_TOKEN}"}
}

The agent manages local processes the same way it manages remote HTTP servers — same tool, same lifecycle, same HITL gating.

Integration with Credential Store

Server configurations often need credentials — API keys, auth tokens, OAuth secrets. manage_mcp integrates with Facio's credential store through the same ${credentials.KEY} placeholder syntax:

manage_mcp(action="add", name="github", config={
  "command": "npx",
  "args": ["-y", "@anthropic/mcp-server-github"],
  "env": {"GITHUB_TOKEN": "${credentials.GITHUB_TOKEN}"}
})

The agent composes a configuration referencing a secret it cannot read. The credential store resolves the placeholder at server start time. The agent never sees the token. The server gets exactly what it needs.

This is the same write-time placeholder resolution that works for write_file and edit_file — extended to server lifecycle management. The agent manages infrastructure that depends on secrets it can't access. The architecture handles the gap.

Audit Trail: Every Server Change Is Tracked

Every manage_mcp operation — add, remove, edit, enable, disable, restart — is captured in Facio's audit trail. You can trace exactly:

• When a server was added and by which agent
• Who approved the addition (human audit record)
• When a server was disabled and why (agent logged the reason)
• Which configuration changes were made and when
• Server uptime and restart history

This transforms MCP server management from an ops team's manual task into an auditable, agent-driven process with human oversight at every destructive step.

Bottom Line

MCP has standardized how AI agents connect to tools. But connecting is only half the problem. Managing — toggling, reconfiguring, restarting, and auditing — is where production systems live or die.

Facio's manage_mcp turns server management into a runtime primitive the agent can use directly, with automatic transport negotiation, credential-safe configuration, HITL gating on destructive changes, and full audit trail coverage. The agent doesn't just use tools — it manages its own tool infrastructure.

In a production environment with dozens of MCP servers, that's the difference between an agent that fails gracefully and one that waits for a human to read the logs.

---

See the MCP management documentation for transport negotiation details, HITL approval patterns, and server lifecycle best practices.