My MCP Server Kept Crashing. Here's the Error Recovery Pattern That Saved It.

A developer built a resilient error recovery pattern for MCP servers after experiencing silent crashes. The pattern wraps tool handlers to catch exceptions and return structured error responses with isError: True, preventing AI agents from hallucinating based on garbage text. The solution has been running on two production servers for three weeks with zero silent failures.

I spent three days wondering why my MCP server would just... stop. No crash logs. No error messages. Clients connected fine, then after a few hours, every tool call returned silence. Turns out the Model Context Protocol MCP spec doesn't force you to handle errors — it assumes you will. But the reference implementations are minimal. Your server starts healthy, then bit by bit, things go wrong. A network blip. A malformed tool argument. An external API timeout. And suddenly your AI agent is staring at a blank response. Here's the pattern I ended up with. It's not clever. It just works. Start with a wrapper around your tool handlers. Every MCP server framework has some kind of tool registration — this works for the official Python SDK, the TypeScript SDK, and most community frameworks: python from mcp.server import Server from mcp.types import ErrorData, INTERNAL ERROR, INVALID PARAMS import traceback import json class ResilientMCPServer Server : """An MCP server that doesn't silently die.""" async def call tool self, name: str, arguments: dict : try: result = await super .call tool name, arguments return result except ConnectionError, TimeoutError as e: Network-level issues — reconnect and retry self. reconnect return self. error response f"Connection lost while executing {name}: {e}" except ValueError as e: Bad arguments from the client — tell them clearly return self. error response f"Invalid arguments for {name}: {e}", code=INVALID PARAMS except Exception as e: Everything else — log, don't crash traceback.print exc return self. error response f"Tool {name} failed: {e}", code=INTERNAL ERROR def error response self, message: str, code: int = INTERNAL ERROR : return { "content": {"type": "text", "text": f"ERROR: {message}"} , "isError": True } def reconnect self : """Reset transport layer without restarting the server.""" Your reconnection logic here pass The key detail most people miss: set isError: True in the response . Without it, the client treats your error message as a successful result. Your AI starts hallucinating based on garbage text. Let me break down what each exception type maps to in practice. ConnectionError / TimeoutError — These happen when your MCP server talks to an external API or database. The STDIO transport itself won't throw these, but your tool handlers will when they call out to the internet. I reconnect the transport layer instead of restarting the process, which drops the ongoing request but keeps the server available for the next one. ValueError — Your AI client sent garbage arguments. Maybe it invented a parameter name, passed a string where a number was expected, or sent an empty array. Instead of crashing, tell it exactly what was wrong. I've seen Claude and GPT both self-correct on the next tool call when they get a clear error. Exception catch-all — Everything else. Third-party SDK threw something unexpected. A file was missing. Memory ran out. The catch-all logs the full traceback so you can fix it later, returns a clean error to the client, and keeps the server running. Your agent loses one response but not the whole session. MCP has a built-in error reporting mechanism through isError , but the SDKs don't enforce it. If your tool handler throws an unhandled exception: isError: True isError , the client The wrapper pattern guarantees three things: isError: True tells the LLM "this response is an error, don't use it"I've been running this pattern on two production MCP servers for three weeks. Zero silent failures since the deployment. Before the wrapper, I was getting about one per day. Don't catch everything blindly. Some errors should crash the server — config validation failures, missing environment variables, corrupted state. I use a separate FatalError exception class for those: class FatalError Exception : """Errors that should kill the server process.""" pass In the wrapper: re-raise FatalErrors except FatalError: raise Let it crash — better than running corrupted The rule of thumb: if the error means all future requests will also fail , crash. If it's transient or specific to one request, catch it. Be careful with reconnection in shared-state servers. If your MCP server maintains in-memory state caches, active connections , a reconnect might leave stale references. I added a health check tool that clients can call to verify the server is in a good state: php @server.tool async def health check - dict: return { "status": "ok", "connections active": len pool. connections , "cache size": len cache. store } This is especially useful when using MCP over Streamable HTTP transport. A transport-level reconnect resets the HTTP connection but leaves your in-memory caches intact — which is exactly what you want, as long as those caches aren't holding stale connections. The isError flag is per-response, not per-stream. Each tool call response can independently signal success or failure. This means partial failures are possible — handle them explicitly rather than aborting the whole batch. If one of your tools queries five APIs and three fail, you can return: { "content": {"type": "text", "text": "Fetched data from API-A, API-B, API-C. API-D and API-E timed out."} , "isError": True } The client gets the partial data and a clear signal that something failed. The LLM can decide to retry the failed ones or proceed with what it has. Don't underestimate how much a structured log helps when things go wrong. I added a simple JSON logger that captures every tool call and its outcome: python import logging import json mcp logger = logging.getLogger "mcp.server" handler = logging.FileHandler "mcp errors.log" handler.setFormatter logging.Formatter '% asctime s | % levelname s | % message s' mcp logger.addHandler handler In your wrapper mcp logger.error json.dumps { "tool": name, "error": str e , "type": type e . name } This saved me twice already — once when I spotted a pattern of timeout errors pointing to a rate-limited API, and once when a ValueError from the client revealed a prompt that was generating malformed tool calls. Have you run into silent MCP server failures? How do you handle tool-level errors in your agent infrastructure? I'm still figuring out the edges — especially around long-running tools that timeout mid-execution.