Add instructions to Everything Server

[olaservo]

Description

Adds instructions to demonstrate this feature for clients that support it.

Edited from my original example to follow best practices notes sourced from related discussions, latest changes summarized by Claude below:

1. Be Concise and Clear

• Transformed from 200+ word feature documentation to focused 130-word usage guide
• (edit - removed some language around subscribing to avoid confusion)
• Eliminated verbose explanations in favor of direct guidance

2. Focus on Workflows and Dependencies

• Documented tool execution order (subscribe → notifications → sampling)
• Explained conditional logic (subscription automatically triggers sampling)
• Highlighted dependencies (progress notifications require _meta.progressToken)

3. Avoid Redundancy with Tool Descriptions

• Removed descriptions that duplicate individual tool functionality
• Focused on "bigger picture" system behaviors rather than what specific tools do
• Emphasized how tools work together instead of their individual capabilities

4. Include Performance Considerations and Limitations

• Specified all timing intervals (10s resource updates, 20s log messages, 30s stderr)
• Documented resource patterns (even IDs = text, odd IDs = binary)
• Noted pagination limits (10 items per page) and cursor-based navigation

5. Provide Contextual Guidance

• Explained unique server behaviors (automatic sampling on subscription)
• Documented multi-modal testing capabilities
• Included argument completion and resource template features

6. Educational Enhancement

• Added easter egg to demonstrate instructions feature working
• Provides interactive proof that client properly passes instructions to LLM
• Serves as both test and educational tool for the instructions feature

Server Details

• Server: server-everything
• Changes to: initialization info

Motivation and Context

This is not yet a well-known feature of MCP, so including an example here could help increase visibility.

How Has This Been Tested?

Tested in Inspector:

Breaking Changes

None

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

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 (Inspector)
• 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

[olaservo]

@evalstate after talking about instructions in Inspector I thought it might be good to add this. However since I haven't been actively using this feature in the context of an actual host/LLM using these instructions from a server, I wanted to gut check a couple things:

• Since these instructions are seen during initialization, should they be used a way for the host/LLM to get a sneak peek of the available Tools, Prompts, Resources without having to load all of the more verbose info (descriptions, etc.)? That's basically what I'm doing here.
• Besides that, I'm assuming that anything you'd put into a system prompt could belong here. Does it make sense to include anything explicit about how to handle the lack of certain client capabilities? For example: if a client like Claude Desktop doesn't support completion, would it be reasonable for this to provide alternative suggestions through the LLM?

I can also tinker with these first hand but thought you might have more experience with it. Thanks!

[evalstate]

This is great @olaservo.

There is an example in the Base Protocol Lifecycle page has "instructions": "Optional instructions for the client" and the schema says:

  /**
   * Instructions describing how to use the server and its features.
   *
   * This can be used by clients to improve the LLM's understanding of available tools, resources, etc. It can be thought of like a "hint" to the model. For example, this information MAY be added to the system prompt.
   */
  instructions?: string;
}

Yes, this would usually be added to the System Prompt to describe the scenarios under which the toolset would be used, or how tools/resources may be used together. The MCP Prompts I would not expect to be in here, but Resources may (as they actually do have an LLM facing description field).

[cliffhall]

LGTM! 👍

[olaservo]

Converting back to Draft to revise this to be closer to recent discussions around uses for this field.

[evalstate]

For example: if a client like Claude Desktop doesn't support completion, would it be reasonable for this to provide alternative suggestions through the LLM?

Just realised I didn't answer that (sorry not been tracking the discussion). I would say so -- for example mcp-hfspace has a "Claude Desktop" mode that handles multi-modal content differently. This seems like a good place to advise that e.g. "Audio Content is not playable by Claude Desktop, but files are made available to the User" in that mode.

[cliffhall]

I pinged you in the Discord about a slight change.

The contents of instructions.md just made me aware that the server is erroneously triggering a sampling request on subscriptions. We could fix that by removing line 281 of everything.ts and removing this passage from instructions.md

- subscription automatically triggers sampling request to client

Or I could do that in a subsequent request. I'm approving because I tested and all else seems fine. If you'd like to merge this, I'll follow up. Or if you agree and want to make that slight change here, I'll test and approve again.

[cliffhall]

Slight rewording of the resources part.

[cliffhall]

Suggested change

	Testing and demonstration server for MCP protocol features. Workflow: Subscribe to resources before testing notifications - subscription automatically triggers sampling request to client. Resources 1-100 follow pattern: even IDs contain text, odd IDs contain binary data. Resources paginated at 10 items per page with cursor-based navigation.
	Testing and demonstration server for MCP protocol features.
	Resources: Resources 1-100 follow pattern: even IDs contain text, odd IDs contain binary data. Resources paginated at 10 items per page with cursor-based navigation.

[cliffhall]

If removing the verbiage about subscription/sampling, this line should change, too. As for "Workflow:..." there's really no need to subscribe before testing notifications. They come to you automatically.

[olaservo]

Makes sense - I simplified this part as you suggested. (Although the GitHub UI wouldn't allow me to apply the suggestion directly so you might want to double check that I got this right.)

[cliffhall]

Just a whitespace change.

[cliffhall]

LGTM! 👍