Testing MCP servers and the agents that use them

An MCP tool that looks correct in isolation can still break an agent in production, because the failure usually lives in how the tool behaves against the real service. Test at both levels.

Test the server in isolation #

Start with the MCP Inspector. It connects straight to your server so you can list tools, call them with sample inputs, and read the raw results, no client or model required. This catches schema mistakes, bad error messages, and auth problems fast.

Test the agent end to end #

Isolated tool tests do not tell you whether the agent uses the tool correctly across a real task: choosing the right tool, passing the right arguments, and handling failures. For that you run the whole agent through realistic scenarios and check the resulting state, not just the transcript.

Test against realistic service behavior, not mocks #

MCP tools wrap real services, and real services rate limit you, reject writes, deliver webhooks out of order, and sometimes send the same event twice. Mocks do none of that, so an agent can pass every mocked test and still break in production. What you test against sits on a spectrum. HTTP mock servers like WireMock or Mockoon let you fake one service and script a delay or an error, which is enough for exercising a single tool's failure handling. When a dependency has a real container image, Testcontainers runs the genuine article, a real Postgres or Redis, inside the test. Neither helps much when the agent coordinates several SaaS at once and needs shared state across them, which is the common shape for MCP agents. A cross-service replica like Arga Labs covers that case, running stateful twins of the services an MCP server wraps so a record written through one tool is visible from another, and letting you inject the rate limits and out-of-order webhooks that only bite in production. Whichever you choose, run the whole agent against it and check the resulting state, not just the transcript.