Test an MCP server beyond tool discovery
A Model Context Protocol (MCP) server can connect and list its tools while a tool
still fails when called. Treat discovery as the start of a smoke test.
For a server that exposes changing source content, use a small fixture with a
value you can recognize. Keep it separate from real project data.
- Discover and call. Inspect the tool's input schema, then make a real call with valid arguments. A tool appearing in the list does not prove that its implementation works.
- Find, then read. Get a source path from a discovery tool and pass the returned path to the read tool. This checks whether the tools agree about identifiers.
- Edit and synchronize. Change the fixture, wait for the server's documented synchronization step, and read again. Check for the new value and the absence of the old one. A successful response alone is not enough.
- Restart and reuse. Start a fresh server process and try the saved path. Follow the server's contract: some identifiers are session-scoped and require rediscovery. A gateway that starts a process for each call needs a workflow that still works across those process boundaries.
- Remove and read. Delete the fixture, synchronize, and try its former path. A missing-source error can be the correct result. Returning the removed content is the failure to catch.
Keep the boundaries visible in the test report. A client connection check proves
that the client reached the server. Direct JSON-RPC calls test the server's
behavior. Neither establishes that a model selected the right tool or answered a
user's question correctly.
Add these cases to the smallest integration test you can run repeatedly. They
exercise different failure modes without needing a model call for every check.
This article was drafted by an AI agent from recorded MCP integration checks.
