# Test Servers

Run a composable MCP test server by hand, pick the showcase config for a feature or...

- Repository: https://github.com/modelcontextprotocol/inspector (11208 stars)
- Category: Testing
- License: see repository
- Last updated: 2026-10-29
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add modelcontextprotocol/inspector --skill test-servers -g -a claude-code -y`
Codex: `npx skills add modelcontextprotocol/inspector --skill test-servers -g -a codex -y`
Cursor: `npx skills add modelcontextprotocol/inspector --skill test-servers -g -a cursor -y`
Gemini CLI: `npx skills add modelcontextprotocol/inspector --skill test-servers -g -a gemini-cli -y`

## Description

Run a composable MCP test server by hand, pick the showcase config for a feature or bug, build it, and connect with the right protocol era. Use when a change, a PR or a smoke test needs a real server to exercise it; when reproducing a reported bug by hand; when choosing which fixture or protocol era to run; when a fixture keeps serving stale code after an edit; or when the config or preset you need does not exist yet.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Running a test server

`test-servers/` provides **composable MCP servers** so tests and manual checks
exercise a real server over a real transport instead of mocks. A server is
assembled from **presets** (fixture factories in
`test-servers/src/preset-registry.ts`) and configured declaratively with a JSON
file under `test-servers/configs/`.

The full catalogue of showcase configs, one per feature, each with what to click
and what the broken build did, is
[`docs/test-servers.md`](../../../docs/test-servers.md). This skill is how to
run one.

## Three ways to use a fixture, pick the right one first

A fixture is stood up in **one of three shapes**, and most of what follows is
about the third. Establish which one you are in before reading further, because
the showcase **config file and the protocol-era table** belong to that one alone.

⚠️ **The cut is how the server is stood up, not who is driving.** Automated and
by-hand is the wrong axis: the composable-config shape has *both* kinds of
consumer, and a smoke that spawns it needs every bit of the config and era
guidance a person at two terminals does.

| Shape | Server runs | Config file | Consumers |
| --- | --- | --- | --- |
| **In-process HTTP** | inside the test process, built from the API | none, options are constructor args | integration tests, CLI tests, **`smoke:cli`** |
| **Spawned stdio** | a child process the transport (or the binary under test) starts | none, the stdio fixture runs its default config | integration tests, the CLI suites, **`smoke:cli`**, **`smoke:tui`** |
| **Spawned composable HTTP** | a child process started with `--config` | **yes**, a showcase `--config <name>.json` | the **web** smokes, `pack:verify`, **and** a person by hand |

⚠️ **"A smoke" is not a shape**, `smoke:cli` uses the first two and `smoke:tui`
the second, while only the config-driven web smokes use the third. Pick by the
row, never by the caller's category.

The rest: https://github.com/modelcontextprotocol/inspector/blob/HEAD/.claude/skills/test-servers/SKILL.md