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. For workflows across several SaaS services, a cross-service replica such as Arga is another option. Whichever you choose, run the whole agent against it and check the resulting state, not just the transcript.