#

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. 2. 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. 3. 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. 4. 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. 5. 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.