MCP Server Testing: Bad Input, Timeouts and Disconnections

An MCP server is software, so it deserves proper testing. This is where your QA skills become a real advantage. MCP server testing means checking the normal path, and also what happens when input is wrong, tools hang or connections drop. In this lesson you will write tests that need no AI model.

---

💡 What to Test in MCP Server Testing

Area	Test idea	Expected result
Discovery	List the tools	The exact expected names appear
Happy path	Call each tool with valid input	Correct content is returned
Bad input	Wrong type or out-of-range value	isError: true and a clear message
Unknown tool	Call a name that does not exist	A protocol error
Missing data	Ask for a test that does not exist	A tool error with a hint
Timeout	Make a dependency hang	The call ends with an error
Disconnection	Stop the server mid-call	The client reports it and recovers
Output channel	Check stdout on a stdio server	Only protocol messages appear
Large output	Return a huge report	The size is limited
Secrets	Inspect logs and results	No keys or passwords appear

---

🔍 Test with a Real Client

Install the client package in the project from Build an MCP Server for QA.

npm install @modelcontextprotocol/client

Create src/server.test.ts. It runs your server inside the test, with no network and no AI model.

import assert from 'node:assert/strict';
import { Client, StreamableHTTPClientTransport } from '@modelcontextprotocol/client';
import { createMcpHandler } from '@modelcontextprotocol/server';
import { createServer } from './create-server.js';

const handler = createMcpHandler(createServer);
const transport = new StreamableHTTPClientTransport(new URL('http://test.local/mcp'), {
  fetch: (url, init) => handler.fetch(new Request(url, init)),
});
const client = new Client(
  { name: 'qa-test', version: '1.0.0' },
  { versionNegotiation: { mode: 'auto' } },
);
await client.connect(transport);

const { tools } = await client.listTools();
assert.deepEqual(tools.map((tool) => tool.name), ['list_failed_tests', 'get_test_error']);

const valid = await client.callTool({ name: 'list_failed_tests', arguments: { limit: 1 } });
assert.notEqual(valid.isError, true);

const badInput = await client.callTool({ name: 'list_failed_tests', arguments: { limit: 999 } });
assert.equal(badInput.isError, true);

const unknownTest = await client.callTool({ name: 'get_test_error', arguments: { name: 'ghost' } });
assert.equal(unknownTest.isError, true);

await assert.rejects(client.callTool({ name: 'delete_all', arguments: {} }));

await client.close();
await handler.close();
console.log('All MCP checks passed');

All MCP checks passed

Run it with npx tsx src/server.test.ts. You can move these checks into your usual test runner later.

To smoke test the real stdio server in a pipeline, use the Inspector’s command-line mode.

npx @modelcontextprotocol/inspector --cli npx tsx src/server.ts --method tools/list

---

🧩 Timeouts and Disconnections

This small program has no dependencies. It simulates a slow tool and a dropped connection.

type ToolResult = { text: string; isError: boolean };

function slowTool(delayMs: number): Promise<ToolResult> {
  return new Promise((resolve) => {
    setTimeout(() => resolve({ text: 'report ready', isError: false }), delayMs);
  });
}

async function withTimeout(
  call: () => Promise<ToolResult>,
  limitMs: number,
): Promise<ToolResult> {
  let timer: ReturnType<typeof setTimeout> | undefined;
  const timeout = new Promise<ToolResult>((resolve) => {
    timer = setTimeout(
      () => resolve({ text: `Timed out after ${limitMs} ms`, isError: true }),
      limitMs,
    );
  });
  try {
    return await Promise.race([call(), timeout]);
  } finally {
    clearTimeout(timer);
  }
}

let drops = 1;
async function flakyReadOnlyTool(): Promise<ToolResult> {
  if (drops > 0) {
    drops--;
    throw new Error('connection closed');
  }
  return { text: 'read after reconnect', isError: false };
}

async function retryReadOnly(call: () => Promise<ToolResult>): Promise<ToolResult> {
  try {
    return await call();
  } catch {
    return await call();
  }
}

async function main() {
  console.log((await withTimeout(() => slowTool(5), 200)).text);
  console.log((await withTimeout(() => slowTool(200), 5)).text);
  console.log((await retryReadOnly(flakyReadOnlyTool)).text);
}

main();

report ready
Timed out after 5 ms
read after reconnect

This timeout stops the waiting, but not the work. Real code should also cancel the operation.

---

🌍 Real-Life Example: The Forever Spinner

A report tool calls an internal service that hangs during a deployment. The tool has no time limit, so the assistant waits without end. A test with a fake hanging service would have caught this. The team adds a time limit and a clear error message.

---

🧪 Try It Yourself

1. Add the test file and run it.
2. Add a check for each row of the test table that applies.
3. Temporarily add a console.log and see what breaks over stdio.
4. Stop the server while the Inspector is connected.
5. Use the prompt below to find cases that you missed.

---

📋 Ready-to-Copy Prompt

You are a senior QA engineer testing an MCP server.

Tool definitions:
[paste tool names, descriptions and schemas with no secrets]

Create test cases for: valid input, wrong types, boundary values, missing
fields, unknown tools, missing data, timeouts, disconnections, large output
and secrets in logs.

Return a table with: ID, Tool, Input, Expected Result, Error Type
(protocol or tool) and Safe to Retry (yes or no).

Do not invent tools or fields that are not listed.

---

⚠️ Common Mistakes

• Testing only through a chat with an AI model
• Writing no tests for bad input
• Leaving tool calls without a time limit
• Retrying write actions automatically
• Assuming that a failed call did nothing

---

🎯 Key Takeaways

• Test MCP servers like any other software interface.
• A real client in test code needs no AI model.
• Every external call needs a time limit.
• Only retry actions that are safe to repeat.

---

🎤 Interview Questions

1. How would you test an MCP server?

Model answer: I would test discovery, valid calls, bad input, unknown tools, missing data, timeouts, disconnections, output limits and logs. I would automate this with a real MCP client and no model.

2. Why test without an AI model?

Model answer: A model adds cost and variation. Using a client directly makes tests fast, free and repeatable, and lets me choose exactly which request is sent.

3. How do protocol errors and tool errors affect your assertions?

Model answer: A protocol error makes the client call fail, so I assert that it rejects. A tool error is a normal result, so I assert that isError is true and check the message.

4. What should happen when a server disconnects during a call?

Model answer: The client should report the failure and can restart a stdio server. The request may be lost, so it should be sent again only if the action is safe to repeat.

5. Why is retrying a tool call risky?

Model answer: A call can succeed even though the response was lost. Retrying a write could repeat the effect, so write tools need idempotency checks or human review.

---

📝 Assignment

Write at least ten automated tests for your server, including one for each error type. Add a fake dependency that hangs, and prove that your time limit works. Record any bug that you find, using the format from Write Better Bug Reports with AI.

---

❓ FAQ

Can I use Playwright Test for these checks?

Yes. Its test runner works well for code-level checks like these. You do not need a browser for them.

Should these tests run in CI?

Yes. They are fast and need no model or API key, so they are a good fit for every pull request.

---

🚀 Next Steps

Well done on finishing this lesson. Complete the assignment, then continue with MCP Tool Design for QA: Browser, File, Test Runner and Report Tools.