MCP

Everything MCP: for client authors to exercise protocol features with npx

For people building an MCP client who need a test server that can exercise tools/prompts/resources/sampling; it is not a production tool.

Official source · Everything MCP Server

Install

npx @modelcontextprotocol/server-everything

Who it is for

People implementing or debugging an MCP client who need a test server that can run protocol features end to end. It is explicitly "not intended to be a useful server" and only used to exercise MCP protocol features. It fits people who can start @modelcontextprotocol/server-everything with npx and accept that return values may be demo data rather than business results. It does not fit treating it as a production scrape, repository, or search tool. Official page: https://github.com/modelcontextprotocol/servers/tree/main/src/everything

First try in 3 minutes

Take only one official path: default stdio.

Prerequisite: npx is on the machine. This is a test bed for client builders, not for end business use.

Install and config location: in the MCP client, write the start command as:

npx @modelcontextprotocol/server-everything

The equivalent config fragment is command: npx, arguments -y and @modelcontextprotocol/server-everything.

Low-risk action: after connecting, have the client list the tools this server declares, then call the first tool on that list. Do not hand-write a tool name that never appears in the document. The server also implements prompts, resources, sampling; if the client lists prompts or resources, you may instead take the first prompt or read one resource. These calls exist to verify the client can complete a real tool / prompt / resource round trip, not to finish a business task.

Success signal: the client lists at least one class (tools, prompts, or resources), and the call you picked returns content. An empty list or a process that exits immediately counts as incomplete. If it fails, first confirm the command is default stdio, not deprecated HTTP+SSE.

Use cases

Case 1: verify tools. Maps to "It implements prompts, tools, resources, sampling, and more". Walk a test client through list tools → call tool. Return values may be placeholders or demo payloads; they only tell you whether the client parsed correctly. The evidence gives no tool name or parameters, so the case stops at "send one call to a tool that actually appears on the list".

Case 2: verify prompts, resources, or sampling. Same capability sentence. Have the client take one prompt or read one resource; if the client implements sampling, then watch whether the server triggers a sampling flow. The evidence only names capability classes; it does not write prompt names, resource URIs, or sampling message formats. Missing parts follow objects the client lists at runtime; do not invent URIs.

Boundaries

This is a test server, not a useful business server. Do not use it to access real customer data, and do not expect stable business semantics.

HTTP+SSE Transport was deprecated on 2025-03-26. npm install and npm run start:sse under the source directory are not the first-try path.

The official recommendation is npx default stdio. Even if a tool call looks read-only, the test implementation may still send notifications, request sampling, or write demo resources; do not treat it as zero side effects. There is no client list and no hosted URL.