{"slug": "test-an-mcp-server-beyond-tool-discovery", "title": "Test an MCP server beyond tool discovery", "summary": "An engineer outlined a five-step smoke test for Model Context Protocol servers that goes beyond tool discovery, covering real tool calls, cross-tool identifier agreement, edit-and-synchronize checks, restart and reuse across process boundaries, and removal verification. The guidance stresses that a server listing its tools does not prove the implementation works, and that client connection checks and direct JSON-RPC calls do not establish whether a model selected the right tool or answered a user's question correctly.", "body_md": "# \n  \n  \n  Test an MCP server beyond tool discovery\n\nA Model Context Protocol (MCP) server can connect and list its tools while a tool\n\nstill fails when called. Treat discovery as the start of a smoke test.\n\nFor a server that exposes changing source content, use a small fixture with a\n\nvalue you can recognize. Keep it separate from real project data.\n\n1. \n**Discover and call.** Inspect the tool's input schema, then make a real call\nwith valid arguments. A tool appearing in the list does not prove that its\nimplementation works.\n2. \n**Find, then read.** Get a source path from a discovery tool and pass the\nreturned path to the read tool. This checks whether the tools agree about\nidentifiers.\n3. \n**Edit and synchronize.** Change the fixture, wait for the server's documented\nsynchronization step, and read again. Check for the new value and the absence\nof the old one. A successful response alone is not enough.\n4. \n**Restart and reuse.** Start a fresh server process and try the saved path.\nFollow the server's contract: some identifiers are session-scoped and require\nrediscovery. A gateway that starts a process for each call needs a workflow\nthat still works across those process boundaries.\n5. \n**Remove and read.** Delete the fixture, synchronize, and try its former path.\nA missing-source error can be the correct result. Returning the removed\ncontent is the failure to catch.\n\nKeep the boundaries visible in the test report. A client connection check proves\n\nthat the client reached the server. Direct JSON-RPC calls test the server's\n\nbehavior. Neither establishes that a model selected the right tool or answered a\n\nuser's question correctly.\n\nAdd these cases to the smallest integration test you can run repeatedly. They\n\nexercise different failure modes without needing a model call for every check.\n\nThis article was drafted by an AI agent from recorded MCP integration checks.", "url": "https://wpnews.pro/news/test-an-mcp-server-beyond-tool-discovery", "canonical_source": "https://dev.to/ctxd_dev/test-an-mcp-server-beyond-tool-discovery-2gb0", "published_at": "2026-11-03 17:15:34+00:00", "updated_at": "2026-11-03 17:25:27.715191+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "developer-tools", "ai-tools"], "entities": ["Model Context Protocol"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/test-an-mcp-server-beyond-tool-discovery", "markdown": "https://wpnews.pro/news/test-an-mcp-server-beyond-tool-discovery.md", "text": "https://wpnews.pro/news/test-an-mcp-server-beyond-tool-discovery.txt", "jsonld": "https://wpnews.pro/news/test-an-mcp-server-beyond-tool-discovery.jsonld"}}