How do you test an MCP server before agents start using it?

Test an MCP server in two passes: first the protocol, with the MCP Inspector, then the answers, with a fixed sheet of questions that includes the ones the server must refuse. A server can pass the first and fail the second, and it is the second that agents will notice.

Choosing a vendor is a different job, covered in the evaluation trial for product teams. This article is for the server you own and are about to open to callers.

Pass one: does the server speak the protocol?

The MCP Inspector is the reference tool for this. Per the MCP documentation (revision 2026-07-28, read on November 10, 2026), it ships as a single package, @modelcontextprotocol/inspector, with three clients on one shared core: a web client, a scriptable CLI client and a terminal client. It needs Node 22.19.0 or newer and runs through npx, with no installation.

For a remote server, the web client opens like this:

npx @modelcontextprotocol/inspector --server-url https://your-server.example/mcp --transport http

The CLI client does the same job without a browser, which makes it the one to put in a pipeline:

npx @modelcontextprotocol/inspector --cli https://your-server.example/mcp --transport http --method tools/list

What you check in this pass:

• The list is what you meant to publish. Names, descriptions, input schemas. Read the descriptions as a model would; they are the only text it has when it chooses. How to write them is another article.
• Each tool runs with valid input and returns something in the expected shape.
• Each tool fails cleanly with invalid input. A malformed argument should produce a readable tool error, not a stack trace.
• Authorization behaves. Call with a valid credential, with none, and with a revoked one. The third must fail.

This pass is cheap and mechanical. It also tells you nothing about truth. Keep going.

Pass two: does it answer correctly?

An agent does not call tools/list for pleasure. It asks a question and trusts the result. So the second pass is a sheet of questions, written before you look at the answers, each with the expected behavior.

Here is a sheet for an illustrative server that answers questions about a product. The questions are invented for the example; adapt the shapes, not the wording.

Two rows deserve more attention than the others. The nonexistent thing and the out-of-scope question are the cases an agent cannot detect on its own. If the server invents an answer, the agent repeats it with the same confidence it gives to true ones. This is the mechanism behind agents hallucinating product features, and the sheet is where you catch it before a customer does.

Make "I don't know" a result you can assert

A refusal is only testable if the server returns it as an explicit result. If "no answer" comes back as an empty string or a timeout, you cannot tell it from a bug.

So decide the shape up front: a field or a stated phrase that means "the server looked and found nothing." Then the sheet can say, for the two refusal rows, expected: the explicit no-answer result. A test that passes on silence passes on a crash.

Run the sheet before and after every change

The sheet earns its keep on the second run. Save the answers from the first one. After each change to a tool, the data, or the code the server reads, replay the same questions and compare.

A differing answer is not automatically a bug; the product may have changed. What you are looking for is a difference nobody expected. If you also rename or remove tools, the sheet is how you see that the answers stayed the same.

Keep the sheet in the repository, next to the server. Review it like code. When a real user hits a wrong answer, add that question; the sheet grows from failures you actually met.

Three traps

Writing the expected answers after reading the real ones. You will agree with whatever the server said. Write the expectation first, even as one line.

Testing only the happy path. Five questions the server answers well tell you less than one it should refuse and doesn't.

Treating one pass as the other. Green in the Inspector means the plumbing works. It does not mean the water is clean.

The objection: "we'll find problems in production, from real users"

You will, and the sheet doesn't replace that. It changes who pays. A wrong answer found in a test costs a line in a file. The same answer found by a customer, through an agent, costs a conversation, and agents rarely say where an answer came from. Run the sheet to catch the failures you can predict, and use production to add the ones you couldn't.

The mirror objection: "a question sheet is too much for a small server"

If the server exposes one tool and you are its only caller, skip most of it: two passes in an hour are plenty. The sheet starts to matter when callers you don't control arrive, or when a wrong answer is expensive. A server that answers questions about a product reaches that point quickly, since a stale answer reads exactly like a correct one.

What DeployIt does here

DeployIt reads the real code (resynced on every push) and the git history, commits and diffs, through its own MCP servers, and checks the code before it asserts anything. Read-only, revocable at any time. The server is in early access / design partner program, and we do not publish its internal test suite here. The principle is the one above: the answers follow the code, so a question sheet replayed after a release shows what the product change did to them. See the MCP server and the living help center.

Frequently asked questions

Can the sheet be generated by a model? It can propose candidates; a person should choose and write the expectations. Generated expectations tend to mirror the server's own answers, which defeats the point.

Where does the Inspector fit in a CI run? The CLI client prints machine-readable output, so a pipeline can call tools/list or a tool and compare the result. Keep the question sheet as a separate step: it needs judgment on the answers, not only a status code.

What if two replays of the same question give different wording? Compare the facts, not the sentence. Wording will vary; the claimed facts and the cited sources should not.

Key takeaways

Two passes: the Inspector for the protocol, a fixed question sheet for the answers. Include the questions the server must refuse, and make the refusal an explicit result. Replay the sheet after every change.

DeployIt is free during early access; paid plans arrive in January 2027. The MCP server is in early access / design partner program, and the program is open.