MCP Server Tester

01 What Is the Model Context Protocol?

In late 2024, Anthropic published the Model Context Protocol (MCP), an open specification for how AI agents discover, call, and consume external capabilities. The problem it solves is familiar to anyone who built agent tooling beforehand: every framework had its own tool format, every integration was bespoke, and a tool written for LangChain did not work in Claude Desktop, which did not work in your custom agent.

MCP standardizes the contract. You define tools, resources, and prompts once on a server, and any MCP-compatible client, Claude Desktop, Cursor, the Anthropic Agent SDK, third-party agent builders, speaks the same protocol and can use your server immediately. Think of it as "LSP for AI tools": the same idea that standardized editor-to-language-server communication, applied to agent-to-tool plumbing.

02 The Wire Protocol in One Page

MCP rides on JSON-RPC 2.0 over one of two transports. stdio is process-to-process: the client launches the server as a subprocess and they talk over stdin/stdout, used for local servers that Claude Desktop spawns from your config file. HTTP + SSE (Server-Sent Events) is network-reachable: the client POSTs JSON-RPC requests to a single endpoint and the server streams responses or notifications back. This tester speaks the HTTP+SSE transport, the only one a browser can reach.

03 Tools, Resources & Prompts

MCP servers expose three kinds of capability, and knowing which is which is the key to debugging one. Tools are the most-used: functions the model invokes with arguments, the same shape as Claude tool use or OpenAI function calling, with a name, description, and JSON Schema input.

{
  "name": "get_weather",
  "description": "Get current weather for a city",
  "inputSchema": {
    "type": "object",
    "properties": { "city": { "type": "string", "description": "City name" } },
    "required": ["city"]
  }
}

The model reads the description and decides when to call; the client invokes tools/call with the name and arguments; the server runs the tool and returns content. Watch for three pitfalls: a vague description ("Get data") leaves the model unable to tell what or when to call; a missing required array lets the model call with no arguments and confuse itself; and an inconsistent response shape breaks clients, tools should return { content: [{ type: "text", text: "…" }] }, not a bare string.

Resources are read-only data the model pulls into context, files, database rows, API responses, identified by a stable URI. resources/list enumerates them and resources/read fetches one; clients may also resources/subscribe for change notifications. Unlike tools, resources are addressable (read the same URI repeatedly) and often user-discoverable in the client UI.

Prompts are parameterized templates the user triggers, not the model, typically surfaced as slash commands. The user picks one, fills in arguments, and the server returns a prompt body (often a system + user message pair) that the client sends to the model. Prompts are how a server ships pre-engineered workflows, like GitHub's MCP server exposing a "summarize PR" command.

04 Common Errors This Tester Catches

• No response to initialize. Almost always a transport mismatch, you pointed an HTTP client at a stdio server, or used the wrong endpoint path.
• initialize succeeds but tools/list is empty. The server is up but tools never registered, a forgotten server.tool(...) call in frameworks that require explicit registration.
• tools/call errors with no useful message. The error format is { "error": { "code": -32000, "message": "…" } }; many servers return a bare "Internal error". Surface a descriptive message instead.
• Streaming hangs. Long-running tools should emit SSE progress notifications. A connection that appears stuck usually means the server is holding the response without heartbeats, and the client times out.
• 401 with confusing headers. MCP's 2025-03-26 revision added OAuth 2.1. A WWW-Authenticate: Bearer realm="…", resource_metadata="…" response is the discovery handshake, follow it to obtain a token. Older API-key servers just want Authorization: Bearer <key>.

05 MCP vs. Other Tool-Use Approaches

The right choice depends on scope. For a single application's internal tools, native function calling is simpler. For tools you want to share across Claude Desktop, Cursor, your own agent, and a teammate's agent, MCP is the standard worth adopting.

06 Where to Start with Server Development

Anthropic ships SDKs in TypeScript, Python, Kotlin, Swift, and Java. The TypeScript SDK lets you stand up a working server in about twenty lines:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
const server = new McpServer({ name: "my-server", version: "1.0.0" });
server.tool("greet", { name: z.string() }, async ({ name }) => ({
  content: [{ type: "text", text: Hello, ${name}! }]
}));

This tester is the natural complement to that loop: write a server, hit it here, see exactly what an agent would see, and iterate. Once a call looks right in the tester, it will look right in Claude Desktop, Cursor, or any other MCP client, because they all speak the same protocol.