New everything server

[cliffhall]

Description

• Refactor/extracted all features from everything.ts into a more modular and maintainable structure.

src/everything
     ├── index.ts
     ├── AGENTS.md
     ├── Dockerfile
     ├── package.json
     ├── tsconfig.json
     ├── docs
     │   ├── architecture.md
     │   ├── extension.md
     │   ├── features.md
     │   ├── how-it-works.md
     │   ├── instructions.md
     │   ├── startup.md
     │   └── structure.md
     ├── prompts
     │   ├── index.ts
     │   ├── args.ts
     │   ├── completions.ts
     │   ├── simple.ts
     │   └── resource.ts
     ├── resources
     │   ├── index.ts
     │   ├── files.ts
     │   ├── session.ts
     │   ├── subscriptions.ts
     │   └── templates.ts
     ├── server
     │   ├── index.ts
     │   ├── logging.ts
     │   └── roots.ts
     ├── tools
     │   ├── index.ts
     │   ├── echo.ts
     │   ├── get-annotated-message.ts
     │   ├── get-env.ts
     │   ├── get-resource-links.ts
     │   ├── get-resource-reference.ts
     │   ├── get-roots-list.ts
     │   ├── get-structured-content.ts
     │   ├── get-sum.ts
     │   ├── get-tiny-image.ts
     │   ├── gzip-file-as-resource.ts
     │   ├── toggle-logging.ts
     │   ├── toggle-subscriber-updates.ts
     │   ├── trigger-elicitation-request.ts
     │   ├── trigger-long-running-operation.ts
     │   └── trigger-sampling-request.ts
     └── transports
         ├── sse.ts
         ├── stdio.ts
         └── streamableHttp.ts

Key Differences

Feature Naming

• Naming of tools and prompts are now in kebab-case as are files.

Logging

• Simulated random-leveled logging messages are now opt-in and toggled on or off by a tool.

Resources

• The dynamic text/blob resources that formed the resource list are now only accessed via resource templates and are no longer odd/even or upper-bounded. The Dynamic Text Resource and Dynamic Blob Resource templates both take a positive integer and return a dynamically created resource with an included timestamp.
• The listed resources are the files found in the docs/ folder, and demonstrates exposing actual static filesystem resources.
• Simulated updates of subscribed resources are now opt-in, toggled on or off by a tool.
• A new concept - session resources - is implemented and the gzip-file-as-resource tool demonstrates it. A file is compressed by the tool and then added as a session resource, which is available for the duration of the session and is listed along with the other documents when you list resources. Its URI sets it apart from the static resources.

Prompts

• The prompt complex_prompt is now called args-prompt because it demonstrates prompts with arguments.
• A new prompt completable-prompt demonstrates completable arguments where the selection of the first arg narrows the completions for the second arg.
• The prompt resource-prompt now takes a resourceType argument (Text or Blob).

Tools

• Tools are now presented in alphabetical order by name.
• Some tools have been renamed with the goal of making them all verbs.
  • If the tool is meant to get something like an annotated message, its name has a prefix get-, e.g., get-annotated-message.
  • NOTE: The previous add tool is get-sum but echo remains as is. These two tools demonstrate the same thing: a tool with an input schema that has a different response based on the input. For this reason, I believe we just should keep one, but they both exist for now.
• The zip tool is now gzip-file-as-resource and incorporates changes in this PR by @ochafik
• The structured-contenttools is nowget-structured-content` and provides an enum of city names, returning a different content block for each city.

Roots

• Although there was code that should have done it, the automatic request to a client supporting roots for the initial list was not being sent. The listener for roots/list_changed was set and so when you added some via the Inspector, it would respond with a roots/list request.
  • The problem was that the call for roots needed to happen after the notification/initialized handler was done, otherwise, the request gets lost; the client never gets it.
  • This has been fixed. Screenshot below.
• Now that there should always be a server-cached roots list for each connected client, that is used in the get-roots-list tool, unless for whatever reason, the list isn't present when the tool is run, in which case the list is requested.

Documentation

• README.md is minimal and focused on how to launch and use with agents. It contains links to all the other pages in docs/.
• CLAUDE.md is now AGENTS.md
• The files in docs/ describe Architecture, Project Structure, The Startup Process, Server Features, Extension Points, and How It Works.

NPM Scripts

• Launcher scripts go through dist/index.js rather than pointing to transport manager directly.
  • start:stdio 👉 node dist/index.js stdio
  • start:sse 👉 node dist/index.js sse
  • start:streamableHttp 👉node dist/index.js
• Added prettier
  • prettier:fix
  • prettier:check

Server Details

• Server: everything
• Changes to: literally everything

Motivation and Context

Use new APIs

The existing implementation of the Everything server uses the low-level Server class rather than McpServer which does a lot of heavy lifting. As a result, the code is more complicated than it should be. Since this is meant to be an educational resource, a model for how to build servers with the TypeScript SDK, it should use the latest features wherever possible.

Make it easier to extend

When adding a new feature, such as some of the things we need to add in order to demonstrate the new spec additions, you had to edit multiple places inside the monolithic everything.ts file. Add an input schema in one place, a tool description in another, and the tool request handler in a third. Now all of that goes in a single file and an orchestrator registers the tool (or resource, or prompt). Adding other behaviors like simulated logging and resource subscription updates was tough because there was no pattern to follow. Now it is easy to do with those examples in place to follow.

Add more inline and high-level documentation

Since this server is intended to exercise all of the MCP features, having all the code in a single, monolithic file made it hard to understand and reason about. Further, because of the size of the file, inline documentation was dissuaded as it only made scrolling to a feature area a longer journey. Breaking all the features out into separate files allowed for much better function docs and inline comments. And the system itself is now more fully documented in a set of markdown files, which the server exposes as resources (and the README.md links to).

How Has This Been Tested?

Locally with the Inspector on the branch for support of the new spec's Elicitation Enum shapes modelcontextprotocol/inspector#952. This feature will be in 0.18.0.

Screenshots

Most of the tools, prompts, and resources operate in the same fashion as previously. Here are some screenshots showing new behavior.

Initial roots/list request now being sent and list received.

Resources now include static files and templates for dynamic text and blobs.

New completable-prompt demonstrates two stage argument filtering

• Choose department from list

• Employees shown are only those in selected department

• Final result combines both arguments

New toggle-subscriber-updates tool

• Simulated Resource Subscription updates are no longer sent automatically, but toggled with a tool that provides more information about what is happening.

New toggle-simulated-logging tool

• Simulated logging is also no longer sent automatically, but instead turned on or off with a tool that provides more information about what is happening.

Renamed gzip-file-as-resource tool creates session resource

• Resource or resource link is returned when running tool

• Resource exists in resource list for duration of session with URI that marks it as a session resource rather than static.

Breaking Changes

Yes. Tools and Resources are named differently, but the way that you launch it has not changed, so it shouldn't actually affect anyone.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Code refactor

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

This fixes #3080

[olaservo]

This discussion question made me think we could add something like this, to demonstrate a collection of resources?

[cliffhall]

This discussion question made me think we could add something like this, to demonstrate a collection of resources?

@olaservo This sounds good. I also want to add icons to everything that supports them. Maybe we can do this as separate PRs?

UPDATE: I added this issue for the resources collection example and assigned to both of us, just so it doesn't get lost in the wash.

Requests resolved.

[domdomegg]

nit: The convention I've generally seen for prompts and tool names is snake_case - is there a reason we're using kebab case? Seems good to follow conventions where we can in case agents use this to see how to implement particular features etc. and pick up on patterns.

[cliffhall]

The snake_case convention comes mainly from Python server development, where it matches Python idioms. The point of deviating here is that it illustrates that snake is a convention, but tool names can be whatever you want them to be within the allowed parameters.

If you go by convention on the hopes of appeasing models that somehow respond to snake_case better, you to cede the DevX benefit entirely to Python. You reinforce a trend that's already self-abetted by LLMs spitting out Python by default when someone asks for an MCP server. If you mix case in your app, with kebab-case files and snake_case primitive names, it will inevitably lead to a mix of cases in your filesystem where either case is admitted.

A kebab-case primitive can line up with thev TypeScript file name that registers it. All the benefit of having a single case pattern for naming at the runtime and filesystem levels, just with TS friendly idioms.

It's a design choice one can make. Making it, particularly in this instructive resource, could end up helping LLMs not to overfit on Python idioms.

[PederHP]

I recall looking at evals showing snake_case and PEP 8 style guidelines performed better. Prompts aren't a model-facing capability, so it doesn't make too much of a difference here.

But you're right that it's a self-reinforcing convention. I sadly think we've passed the point where it's difficult to fight (the C# MCP SDK converts from PascalCase to snake_case when using reflection-based convenience, last I checked, unless overriden, for this very reason). Models simply do better with Python-style tools names.

I am generally in favor of using idiomatic names for the language a server is written, however, and then doing any mapping in a library or even on the client side. Because some models might do better with kebab-case. A model which is using code mode using TypeScript might prefer kebab-case.

[domdomegg]

Generally LGTM, very excited about this! Thank you :)

[olaservo]

This looks good to me - I think we can merge this and start adding the other couple of examples we've mentioned.

I also did one more claude-driven Playwright test run for all the features for each transport using inspector v 0.18.0, along with manual testing for stdio and didn't run into any errors.