Mcp tool reliability

The Model Context Protocol (MCP) is a standard way to give a model tools that live in a separate process or service. The agent connects to an MCP server, asks what tools it offers, and calls them. What this changes for reliability is ownership: the tools your agent depends on are now someone else's deployment, updated on someone else's schedule.

Four things go wrong because of that.

Errors come back in two shapes, and servers mix them up. A tool that ran and failed is supposed to return a normal result marked as an error, with the reason in the content, so the model can read it and try something else. A protocol problem, like an unknown tool or a malformed request, comes back as a protocol error the model never sees. When a server reports a tool failure as a protocol error, the agent has no way to recover from it.

Tool definitions change under you. Clients cache the list of tools, a server is supposed to announce when its tools change, and a client that misses that announcement builds arguments for a tool that no longer looks like that.

Slow servers become agents that never return. Every request needs a timeout, and the timeout has to hold even while the server keeps sending progress updates.

Cancellation differs by transport. Over HTTP, closing the stream is the cancel. Over stdio, it's an explicit message, and both sides have to cope with a response that arrives after the cancel anyway.

Evaluating an MCP server means testing each of these on purpose: return a failed tool result, change a schema mid-session, stall a response, cancel a call, and check what the agent does.