# Test an MCP server beyond tool discovery > Source: > Published: 2026-11-03 17:15:34+00:00 # 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. 1. **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.