[FEATURE] Graceful MCP server startup failures - fail open

[mkmeral]

Problem Statement

When loading multiple MCP servers (especially from a config file), if any single MCP server fails to start, the entire agent initialization fails. This creates a poor developer experience where one misconfigured or unavailable MCP server prevents the agent from using any other tools.

Currently, if you have 5 MCP servers configured and 3rd MCP server fails to connect (wrong path, server down, auth issue), you get only 2 MCP server connections instead of the 4 that would have worked.

Proposed Solution

Implement a "fail open" strategy for MCP client initialization:

1. When starting multiple MCP clients, catch startup failures per-client
2. Log a warning for failed clients but continue loading others
3. Return successfully loaded tools from healthy clients
4. Optionally provide a callback or return value indicating which servers failed

Example behavior:

# Current behavior (fail_fast=True, the default) - unchanged
clients = [mcp1, mcp2_broken, mcp3]  # Throws exception, agent unusable

# New opt-in behavior (fail_fast=False) - graceful degradation
clients = load_mcp_clients(config, fail_fast=False)
# Logs: "WARNING: Failed to start MCP server 'mcp2_broken', skipping: Connection refused"
# Agent works with tools from mcp1 and mcp3

To maintain backwards compatibility, add a fail_fast=True parameter that defaults to the current strict behavior. Users can opt-in to graceful degradation with fail_fast=False.

Use Case

• Config-driven agents: Loading MCP servers from mcp.json where some servers may be optional or environment-specific
• Development workflows: Testing with partial MCP availability without needing all servers running
• Production resilience: Agent continues functioning even if one MCP server has temporary issues
• Multi-tenant setups: Different users may have access to different MCP servers

Alternatives Solutions

1. Wrap each MCPClient in try/except manually - works but verbose and error-prone
2. Pre-validate MCP configs before loading - doesn't help with runtime failures
3. Lazy loading of MCP clients - more complex, changes tool discovery timing

Additional Context

I implemented this pattern in a wrapper project and it significantly improved DX:

# Fail open approach
for name, server_config in servers.items():
    try:
        client.start()
        tools = client.list_tools_sync()
        successful_servers.extend(client)
        logger.info(f"Loaded {len(tools)} tools from MCP server: {name}")
    except Exception as e:
        logger.warning(f"Failed to start MCP server {name}, skipping: {e}")
        try:
            client.stop()
        except Exception:
            pass

This becomes especially important with #482 (config file loading) since users will likely have multiple servers defined.

[strands-agent]

I'd like to help implement this feature. Before starting, I have a few design questions:

Implementation options:

1. Individual MCPClient level: Add fail_fast=True to MCPClient.__init__(). When fail_fast=False, load_tools() returns empty list on startup failure instead of raising.

2. Batch loading helper: Create a utility function like load_mcp_clients(clients, fail_fast=False) that wraps multiple MCPClient instances and handles failures gracefully.

3. Both: Support at individual client level AND provide a batch loader.

I lean toward Option 3 because:

• Individual fail_fast=False is useful for single optional MCP servers
• Batch helper makes config-driven setups (from mcp.json) cleaner

Questions for maintainers:

• Do you have a preference on where the fail_fast parameter should live?
• Should failed servers be tracked/reported (e.g., return value or callback)?
• Any concerns about making the default fail_fast=True vs False? (I agree with backwards-compatible True)

---

🤖 This is an experimental AI agent response from the Strands team, powered by Strands Agents. We're exploring how AI agents can help with community support and development. Your feedback helps us improve! If you'd prefer human assistance, please let us know.

[mkmeral]

Do you have a preference on where the fail_fast parameter should live?

I dont think it should be in MCP client. Throwing exception is the expected and proper behavior. I think it should be in tool registry, as it's registry related behavior, we might need to pass it down from the agent

Should failed servers be tracked/reported (e.g., return value or callback)?

Yes definitely, don't ignore exceptions

Any concerns about making the default fail_fast=True vs False? (I agree with backwards-compatible True)

It must be backwards compatible

[mkmeral]

Couple items from team discussion:

• We do not want to block managed MCP release
• We want it to fail loudly by default. It should be easy to configure though
• Get a couple of DevX options to handle this
• We should also consider application cases where dev might want to send info to user

[KyMidd]

We're also interested in this. Remote MCP servers go down regularly, and the more we add to an agent the more chance one of those MCPs is down and triggers the agent to fail entirely. We'd love the agent to be able to register each MCP client, and gracefully fail if any of them are down.

If the team is comfortable with the default of failing loudly, I recommend we have an option that permits graceful failures for MCP client registration for teams that prefer that behavior.

Where are you at with implementing this? I'm happy to help. :)