# Everything — MCP Server

> The reference server that exercises every part of the MCP spec.

**Source:** https://mcpplaygroundonline.com/mcp-servers/everything  
**Transport:** stdio  
**Requires auth:** No

---

## What it does

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.

## Tools exposed

- echo / get-sum — trivial tools, for checking basic call-and-response
- trigger-sampling-request — server asks the client to run an LLM completion
- trigger-elicitation-request / trigger-url-elicitation — server asks the user for input mid-call
- trigger-long-running-operation — emits progress notifications over several steps
- get-roots-list — reads back the roots the client advertised
- get-annotated-message / get-structured-content — annotations and structured tool output
- get-resource-links / get-resource-reference — resource links returned from a tool
- toggle-simulated-logging / toggle-subscriber-updates — log levels and resource subscriptions
- get-tiny-image / gzip-file-as-resource — image and binary content handling

## Example queries you can run

- "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."

## Details

- **Recommended model:** openai/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.
- **Transport:** stdio
- **Authentication:** Not required — No credentials and no external calls. Everything it returns is generated locally for test purposes.
- **Official source:** [Everything MCP Server — official reference implementation](https://github.com/modelcontextprotocol/servers/tree/main/src/everything)

## Connecting to Everything

### 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 streamableHttp
```

## Frequently asked questions

### What is the Everything MCP server?

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.

### Is it useful for actual work?

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.

### What does it test that a normal server does not?

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.

### Which transports does it support?

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.

### How do I use it to debug my own client?

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.

---

_Test this server across 40+ models on MCP Playground: https://mcpplaygroundonline.com/mcp-servers/everything — free, no install._