MCP Everything Server

The kitchen-sink reference MCP server that exercises every corner of the Model Context Protocol

Free· Free and open source (MIT License). No cloud service or paid tier — you run it locally via npx, Docker, or your MCP client of choice.MCP Servers

Visit website →

Best for

Developers building or hardening MCP clients (IDE plugins, agent frameworks, chat hosts) and server authors who want a canonical, spec-tracking example of every primitive implemented correctly.

Skip if

End users looking for an actual productivity tool — this server intentionally does nothing useful. Also not for teams that need a stable API surface, since it changes as the MCP spec evolves.

MCP Everything Server is the official reference implementation from the Model Context Protocol project that intentionally exercises every feature of the MCP spec in a single server. It is not meant to be useful as a productivity tool — it is a test fixture and teaching artifact for developers building MCP clients (IDE integrations, agent frameworks, chat hosts) and, increasingly, for developers writing their own MCP servers who want a canonical example of how each primitive should behave.

Under the hood it registers roughly fourteen tools that cover the boring-but-important surface area: echo and get-sum for basic input validation with Zod, get-env and get-tiny-image for environment and binary payloads, gzip-file-as-resource and get-resource-links for dynamic per-session resources, get-structured-content for tool responses that conform to a JSON schema, get-annotated-message for priority/audience metadata, trigger-long-running-operation for progress notifications and cancellation, plus toggles for simulated logging and resource-update subscriptions. Four prompts demonstrate static, argument-taking, autocomplete-completable, and resource-embedding prompt patterns. Beyond that, it exercises sampling (letting the server ask the client's LLM to generate text), elicitation (form-mode and URL-mode user prompts), roots discovery, multi-level logging with client-controlled filtering, resource subscriptions, and the newer SEP-1686 Tasks flow for bidirectional long-running operations.

It ships as a TypeScript/Node package and speaks stdio, the deprecated HTTP+SSE transport, and the current Streamable HTTP transport, so client authors can regression-test all three wire protocols against one server. Typical workflows: point a new MCP client at it via `npx @modelcontextprotocol/server-everything`, walk each capability tab in Inspector, and confirm your client renders annotations, honors log-level filters, handles sampling round-trips, and doesn't deadlock on cancellation. For server authors it doubles as a copy-paste corpus for correctly-shaped handlers.

Editor's take

If you are writing an MCP client and you are not pointing it at Everything, you are testing on hope. It is the closest thing MCP has to a conformance suite, and the fact that it is maintained inside the reference-servers repo means it moves in lockstep with the spec. Boring on purpose, essential in practice.

— The AI Tool Bible editorial team

Pros

✅ Only server that exercises the full MCP feature matrix in one place — tools, resources, prompts, sampling, elicitation, roots, logging, subscriptions, and Tasks
✅ Maintained by the Model Context Protocol project itself, so behavior tracks the spec as it evolves (SEP-1686 Tasks, Streamable HTTP, etc.)
✅ Runs anywhere an MCP client runs — npx, Docker, Claude Desktop, VS Code, Cursor, Windsurf — with stdio or HTTP transports
✅ TypeScript source is short and readable, making it a de-facto reference for how each handler should be shaped
✅ MIT-licensed, no telemetry, no signup, no cloud dependency
✅ Includes progress notifications and cancellation flows that most tutorial servers skip, so client cancel/timeout logic can be exercised properly

Cons

⚠️ Explicitly not useful for end users — it does not do anything a human would actually want done
⚠️ Feature drift means some primitives (SEP-1686 Tasks, elicitation) may not yet be implemented in every client, producing red herrings during testing
⚠️ Documentation is a single features.md; there is no guided tour that maps each tool to the spec section it exercises
⚠️ TypeScript-only reference — Python or Rust client authors have to translate patterns themselves
⚠️ Sampling and elicitation flows depend on the client honoring them, so a silent client makes it hard to tell whether the server or the client is at fault

Use cases

MCP client conformance testingRegression testing of stdio and Streamable HTTP transportsVerifying sampling round-trip behavior in a new agent hostDebugging elicitation UI in an IDE integrationReference reading for authoring a new MCP serverDemoing MCP primitives in workshops and talksSmoke-testing cancellation and progress-notification handlingValidating resource-subscription update delivery