Everything is not a server you connect to get work done — it is the one you connect to find out whether your client works. It implements every primitive in the MCP specification, including the parts most servers never touch: sampling, elicitation, roots, progress notifications, completions and resource subscriptions.
Bring your own
GPT-5.4 mini
Chat with 60+ AI models on the same workflow — switch to a different model mid-conversation and re-run the same prompt, or use Compare mode to put several side-by-side and balance quality vs. cost.
No token required
How models use it and what it is built for.
Most MCP servers exercise a thin slice of the protocol — a handful of tools, maybe a resource or two. That makes them poor test subjects, because a client can appear to work perfectly while having no implementation of sampling or elicitation at all. Everything closes that gap deliberately. Its seventeen-odd tools are each there to trigger a specific protocol behaviour rather than to be useful: `trigger-sampling-request` makes the server ask your client to run an LLM completion, `trigger-elicitation-request` makes it ask the user a question mid-tool-call, `trigger-long-running-operation` emits progress notifications, `get-roots-list` reads back the roots your client advertised, and `get-annotated-message` returns content carrying priority and audience annotations. It also serves four resource types — dynamic text, dynamic blobs, static documents and session-scoped resources — plus four prompts covering arguments, completions and embedded resources. It runs over stdio, SSE and Streamable HTTP, so you can test transport handling too.
Typical tools an AI model can call. Exact names vary by version.
Taken from the official Everything documentation — see Everything MCP Server — official reference implementation for the full reference.
Client configuration
npx over stdio
The default. Add an explicit transport argument to test SSE or Streamable HTTP instead.
{
"mcpServers": {
"everything": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-everything"]
}
}
}Streamable HTTP
Runs the same server over the current HTTP transport, which is what you want when testing a remote client path.
npx -y @modelcontextprotocol/server-everything streamableHttpCopy any of these into MCP Agent Studio after connecting.
List every tool, resource and prompt this server exposes and describe what each one tests.
Call the long-running operation and show me the progress notifications as they arrive.
Trigger a sampling request and tell me whether my client handled it.
Read a dynamic resource and then subscribe to updates on it.
This is not a single-model product: you get the same MCP connection with 60+ models (Claude, GPT, Gemini, DeepSeek, open-weight, and more), you can switch mid-conversation, and you can open Compare mode to run the same prompt against multiple models at once. The card above is a suggested starting point for this server — not the only choice.
Default pick for Everything
GPT-5.4 mini
You are testing the client, not the model. A cheap fast model exercises the protocol paths just as well and costs almost nothing to run repeatedly.
Listing tools proves the server is reachable, not that a model can work with it. Evals go further: they read every tool on the server, write a test suite from its real schemas, and run it — code decides pass/fail on the responses (schema conformance, error codes, pagination, result caps) while a scoring model grades plain-English tasks driven through the tools.
Get a pass/fail report per tool with the evidence behind each verdict — and replay the same suite after every schema change. Destructive tools are excluded from the run.
Run evalsOpen MCP Agent Studio with the connection pre-filled. Add your token, pick any of 60+ models, and start chatting — no install required.
Open Agent StudioCommon questions about connecting, scoping and using it safely.
It is the official reference server from the Model Context Protocol project, published as @modelcontextprotocol/server-everything. It implements every MCP primitive and protocol feature so client and SDK authors have something complete to test against.
No, and it is not meant to be. Its tools echo text, add numbers and return a tiny image. Every one exists to trigger a protocol behaviour, not to do something useful — treat it as a conformance fixture, not an integration.
The parts of the spec most servers never use: sampling, where the server asks your client to run a completion; elicitation, where it asks the user a question mid-call; roots; progress notifications; completions; resource subscriptions; and annotations. A client can look healthy against a simple server while implementing none of these.
Stdio by default, plus Streamable HTTP and the deprecated HTTP+SSE transport, selected by a command-line argument. That makes it useful for checking that a client handles the transport layer correctly, not just the message layer.
Connect it and walk the tools one at a time, watching what your client does with each. The sampling and elicitation triggers are the ones that usually expose gaps. You can also point our MCP client tester at it to compare your implementation against a known-good reference.