@modelcontextprotocol/server-everything 2025.12.18 → 2026.1.26

package/README.md

@@ -1,166 +1,17 @@
 # Everything MCP Server
+**[Architecture](docs/architecture.md)
+| [Project Structure](docs/structure.md)
+| [Startup Process](docs/startup.md)
+| [Server Features](docs/features.md)
+| [Extension Points](docs/extension.md)
+| [How It Works](docs/how-it-works.md)**
+
 
 This MCP server attempts to exercise all the features of the MCP protocol. It is not intended to be a useful server, but rather a test server for builders of MCP clients. It implements prompts, tools, resources, sampling, and more to showcase MCP capabilities.
 
-## Components
-
-### Tools
-
-1. `echo`
-   - Simple tool to echo back input messages
-   - Input:
-     - `message` (string): Message to echo back
-   - Returns: Text content with echoed message
-
-2. `add`
-   - Adds two numbers together
-   - Inputs:
-     - `a` (number): First number
-     - `b` (number): Second number
-   - Returns: Text result of the addition
-
-3. `longRunningOperation`
-   - Demonstrates progress notifications for long operations
-   - Inputs:
-     - `duration` (number, default: 10): Duration in seconds
-     - `steps` (number, default: 5): Number of progress steps
-   - Returns: Completion message with duration and steps
-   - Sends progress notifications during execution
-
-4. `printEnv`
-   - Prints all environment variables
-   - Useful for debugging MCP server configuration
-   - No inputs required
-   - Returns: JSON string of all environment variables
-
-5. `sampleLLM`
-   - Demonstrates LLM sampling capability using MCP sampling feature
-   - Inputs:
-     - `prompt` (string): The prompt to send to the LLM
-     - `maxTokens` (number, default: 100): Maximum tokens to generate
-   - Returns: Generated LLM response
-
-6. `getTinyImage`
-   - Returns a small test image
-   - No inputs required
-   - Returns: Base64 encoded PNG image data
-
-7. `annotatedMessage`
-   - Demonstrates how annotations can be used to provide metadata about content
-   - Inputs:
-     - `messageType` (enum: "error" | "success" | "debug"): Type of message to demonstrate different annotation patterns
-     - `includeImage` (boolean, default: false): Whether to include an example image
-   - Returns: Content with varying annotations:
-     - Error messages: High priority (1.0), visible to both user and assistant
-     - Success messages: Medium priority (0.7), user-focused
-     - Debug messages: Low priority (0.3), assistant-focused
-     - Optional image: Medium priority (0.5), user-focused
-   - Example annotations:
-     ```json
-     {
-       "priority": 1.0,
-       "audience": ["user", "assistant"]
-     }
-     ```
-
-8. `getResourceReference`
-   - Returns a resource reference that can be used by MCP clients
-   - Inputs:
-     - `resourceId` (number, 1-100): ID of the resource to reference
-   - Returns: A resource reference with:
-     - Text introduction
-     - Embedded resource with `type: "resource"`
-     - Text instruction for using the resource URI
-
-9. `startElicitation`
-   - Initiates an elicitation (interaction) within the MCP client.
-   - Inputs:
-      - `color` (string): Favorite color
-      - `number` (number, 1-100): Favorite number
-      - `pets` (enum): Favorite pet
-   - Returns: Confirmation of the elicitation demo with selection summary.
-
-10. `structuredContent`
-   - Demonstrates a tool returning structured content using the example in the specification
-   - Provides an output schema to allow testing of client SHOULD advisory to validate the result using the schema
-   - Inputs:
-     - `location` (string): A location or ZIP code, mock data is returned regardless of value
-   - Returns: a response with
-     - `structuredContent` field conformant to the output schema
-     - A backward compatible Text Content field, a SHOULD advisory in the specification
-
-11. `listRoots`
-   - Lists the current MCP roots provided by the client
-   - Demonstrates the roots protocol capability even though this server doesn't access files
-   - No inputs required
-   - Returns: List of current roots with their URIs and names, or a message if no roots are set
-   - Shows how servers can interact with the MCP roots protocol
-
-### Resources
-
-The server provides 100 test resources in two formats:
-- Even numbered resources:
-  - Plaintext format
-  - URI pattern: `test://static/resource/{even_number}`
-  - Content: Simple text description
-
-- Odd numbered resources:
-  - Binary blob format
-  - URI pattern: `test://static/resource/{odd_number}`
-  - Content: Base64 encoded binary data
-
-Resource features:
-- Supports pagination (10 items per page)
-- Allows subscribing to resource updates
-- Demonstrates resource templates
-- Auto-updates subscribed resources every 5 seconds
-
-### Prompts
-
-1. `simple_prompt`
-   - Basic prompt without arguments
-   - Returns: Single message exchange
-
-2. `complex_prompt`
-   - Advanced prompt demonstrating argument handling
-   - Required arguments:
-     - `temperature` (string): Temperature setting
-   - Optional arguments:
-     - `style` (string): Output style preference
-   - Returns: Multi-turn conversation with images
-
-3. `resource_prompt`
-   - Demonstrates embedding resource references in prompts
-   - Required arguments:
-     - `resourceId` (number): ID of the resource to embed (1-100)
-   - Returns: Multi-turn conversation with an embedded resource reference
-   - Shows how to include resources directly in prompt messages
-
-### Roots
-
-The server demonstrates the MCP roots protocol capability:
-
-- Declares `roots: { listChanged: true }` capability to indicate support for roots
-- Handles `roots/list_changed` notifications from clients
-- Requests initial roots during server initialization
-- Provides a `listRoots` tool to display current roots
-- Logs roots-related events for demonstration purposes
-
-Note: This server doesn't actually access files, but demonstrates how servers can interact with the roots protocol for clients that need to understand which directories are available for file operations.
-
-### Logging
-
-The server sends random-leveled log messages every 15 seconds, e.g.:
+## Tools, Resources, Prompts, and Other Features
 
-```json
-{
-  "method": "notifications/message",
-  "params": {
-	"level": "info",
-	"data": "Info-level message"
-  }
-}
-```
+A complete list of the registered MCP primitives and other protocol features demonstrated can be found in the [Server Features](docs/features.md) document.
 
 ## Usage with Claude Desktop (uses [stdio Transport](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#stdio))
 

package/dist/docs/architecture.md

@@ -0,0 +1,44 @@
+# Everything Server – Architecture
+
+**Architecture
+| [Project Structure](structure.md)
+| [Startup Process](startup.md)
+| [Server Features](features.md)
+| [Extension Points](extension.md)
+| [How It Works](how-it-works.md)**
+
+This documentation summarizes the current layout and runtime architecture of the `src/everything` package.
+It explains how the server starts, how transports are wired, where tools, prompts, and resources are registered, and how to extend the system.
+
+## High‑level Overview
+
+### Purpose
+
+A minimal, modular MCP server showcasing core Model Context Protocol features. It exposes simple tools, prompts, and resources, and can be run over multiple transports (STDIO, SSE, and Streamable HTTP).
+
+### Design
+
+A small “server factory” constructs the MCP server and registers features.
+Transports are separate entry points that create/connect the server and handle network concerns.
+Tools, prompts, and resources are organized in their own submodules.
+
+### Multi‑client
+
+The server supports multiple concurrent clients. Tracking per session data is demonstrated with
+resource subscriptions and simulated logging.
+
+## Build and Distribution
+
+- TypeScript sources are compiled into `dist/` via `npm run build`.
+- The `build` script copies `docs/` into `dist/` so instruction files ship alongside the compiled server.
+- The CLI bin is configured in `package.json` as `mcp-server-everything` → `dist/index.js`.
+
+## [Project Structure](structure.md)
+
+## [Startup Process](startup.md)
+
+## [Server Features](features.md)
+
+## [Extension Points](extension.md)
+
+## [How It Works](how-it-works.md)

package/dist/docs/extension.md

@@ -0,0 +1,23 @@
+# Everything Server - Extension Points
+
+**[Architecture](architecture.md)
+| [Project Structure](structure.md)
+| [Startup Process](startup.md)
+| [Server Features](features.md)
+| Extension Points
+| [How It Works](how-it-works.md)**
+
+## Adding Tools
+
+- Create a new file under `tools/` with your `registerXTool(server)` function that registers the tool via `server.registerTool(...)`.
+- Export and call it from `tools/index.ts` inside `registerTools(server)`.
+
+## Adding Prompts
+
+- Create a new file under `prompts/` with your `registerXPrompt(server)` function that registers the prompt via `server.registerPrompt(...)`.
+- Export and call it from `prompts/index.ts` inside `registerPrompts(server)`.
+
+## Adding Resources
+
+- Create a new file under `resources/` with your `registerXResources(server)` function using `server.registerResource(...)` (optionally with `ResourceTemplate`).
+- Export and call it from `resources/index.ts` inside `registerResources(server)`.

package/dist/docs/features.md

@@ -0,0 +1,103 @@
+# Everything Server - Features
+
+**[Architecture](architecture.md)
+| [Project Structure](structure.md)
+| [Startup Process](startup.md)
+| Server Features
+| [Extension Points](extension.md)
+| [How It Works](how-it-works.md)**
+
+## Tools
+
+- `echo` (tools/echo.ts): Echoes the provided `message: string`. Uses Zod to validate inputs.
+- `get-annotated-message` (tools/get-annotated-message.ts): Returns a `text` message annotated with `priority` and `audience` based on `messageType` (`error`, `success`, or `debug`); can optionally include an annotated `image`.
+- `get-env` (tools/get-env.ts): Returns all environment variables from the running process as pretty-printed JSON text.
+- `get-resource-links` (tools/get-resource-links.ts): Returns an intro `text` block followed by multiple `resource_link` items. For a requested `count` (1–10), alternates between dynamic Text and Blob resources using URIs from `resources/templates.ts`.
+- `get-resource-reference` (tools/get-resource-reference.ts): Accepts `resourceType` (`text` or `blob`) and `resourceId` (positive integer). Returns a concrete `resource` content block (with its `uri`, `mimeType`, and data) with surrounding explanatory `text`.
+- `get-roots-list` (tools/get-roots-list.ts): Returns the last list of roots sent by the client.
+- `gzip-file-as-resource` (tools/gzip-file-as-resource.ts): Accepts a `name` and `data` (URL or data URI), fetches the data subject to size/time/domain constraints, compresses it, registers it as a session resource at `demo://resource/session/<name>` with `mimeType: application/gzip`, and returns either a `resource_link` (default) or an inline `resource` depending on `outputType`.
+- `get-structured-content` (tools/get-structured-content.ts): Demonstrates structured responses. Accepts `location` input and returns both backward‑compatible `content` (a `text` block containing JSON) and `structuredContent` validated by an `outputSchema` (temperature, conditions, humidity).
+- `get-sum` (tools/get-sum.ts): For two numbers `a` and `b` calculates and returns their sum. Uses Zod to validate inputs.
+- `get-tiny-image` (tools/get-tiny-image.ts): Returns a tiny PNG MCP logo as an `image` content item with brief descriptive text before and after.
+- `trigger-long-running-operation` (tools/trigger-trigger-long-running-operation.ts): Simulates a multi-step operation over a given `duration` and number of `steps`; reports progress via `notifications/progress` when a `progressToken` is provided by the client.
+- `toggle-simulated-logging` (tools/toggle-simulated-logging.ts): Starts or stops simulated, random‑leveled logging for the invoking session. Respects the client’s selected minimum logging level.
+- `toggle-subscriber-updates` (tools/toggle-subscriber-updates.ts): Starts or stops simulated resource update notifications for URIs the invoking session has subscribed to.
+- `trigger-sampling-request` (tools/trigger-sampling-request.ts): Issues a `sampling/createMessage` request to the client/LLM using provided `prompt` and optional generation controls; returns the LLM's response payload.
+- `simulate-research-query` (tools/simulate-research-query.ts): Demonstrates MCP Tasks (SEP-1686) with a simulated multi-stage research operation. Accepts `topic` and `ambiguous` parameters. Returns a task that progresses through stages with status updates. If `ambiguous` is true and client supports elicitation, sends an elicitation request directly to gather clarification before completing.
+- `trigger-sampling-request-async` (tools/trigger-sampling-request-async.ts): Demonstrates bidirectional tasks where the server sends a sampling request that the client executes as a background task. Server polls for status and retrieves the LLM result when complete. Requires client to support `tasks.requests.sampling.createMessage`.
+- `trigger-elicitation-request-async` (tools/trigger-elicitation-request-async.ts): Demonstrates bidirectional tasks where the server sends an elicitation request that the client executes as a background task. Server polls while waiting for user input. Requires client to support `tasks.requests.elicitation.create`.
+
+## Prompts
+
+- `simple-prompt` (prompts/simple.ts): No-argument prompt that returns a static user message.
+- `args-prompt` (prompts/args.ts): Two-argument prompt with `city` (required) and `state` (optional) used to compose a question.
+- `completable-prompt` (prompts/completions.ts): Demonstrates argument auto-completions with the SDK’s `completable` helper; `department` completions drive context-aware `name` suggestions.
+- `resource-prompt` (prompts/resource.ts): Accepts `resourceType` ("Text" or "Blob") and `resourceId` (string convertible to integer) and returns messages that include an embedded dynamic resource of the selected type generated via `resources/templates.ts`.
+
+## Resources
+
+- Dynamic Text: `demo://resource/dynamic/text/{index}` (content generated on the fly)
+- Dynamic Blob: `demo://resource/dynamic/blob/{index}` (base64 payload generated on the fly)
+- Static Documents: `demo://resource/static/document/<filename>` (serves files from `src/everything/docs/` as static file-based resources)
+- Session Scoped: `demo://resource/session/<name>` (per-session resources registered dynamically; available only for the lifetime of the session)
+
+## Resource Subscriptions and Notifications
+
+- Simulated update notifications are opt‑in and off by default.
+- Clients may subscribe/unsubscribe to resource URIs using the MCP `resources/subscribe` and `resources/unsubscribe` requests.
+- Use the `toggle-subscriber-updates` tool to start/stop a per‑session interval that emits `notifications/resources/updated { uri }` only for URIs that session has subscribed to.
+- Multiple concurrent clients are supported; each client’s subscriptions are tracked per session and notifications are delivered independently via the server instance associated with that session.
+
+## Simulated Logging
+
+- Simulated logging is available but off by default.
+- Use the `toggle-simulated-logging` tool to start/stop periodic log messages of varying levels (debug, info, notice, warning, error, critical, alert, emergency) per session.
+- Clients can control the minimum level they receive via the standard MCP `logging/setLevel` request.
+
+## Tasks (SEP-1686)
+
+The server advertises support for MCP Tasks, enabling long-running operations with status tracking:
+
+- **Capabilities advertised**: `tasks.list`, `tasks.cancel`, `tasks.requests.tools.call`
+- **Task Store**: Uses `InMemoryTaskStore` from SDK experimental for task lifecycle management
+- **Message Queue**: Uses `InMemoryTaskMessageQueue` for task-related messaging
+
+### Task Lifecycle
+
+1. Client calls `tools/call` with `task: true` parameter
+2. Server returns `CreateTaskResult` with `taskId` instead of immediate result
+3. Client polls `tasks/get` to check status and receive `statusMessage` updates
+4. When status is `completed`, client calls `tasks/result` to retrieve the final result
+
+### Task Statuses
+
+- `working`: Task is actively processing
+- `input_required`: Task needs additional input (server sends elicitation request directly)
+- `completed`: Task finished successfully
+- `failed`: Task encountered an error
+- `cancelled`: Task was cancelled by client
+
+### Demo Tools
+
+**Server-side tasks (client calls server):**
+Use the `simulate-research-query` tool to exercise the full task lifecycle. Set `ambiguous: true` to trigger elicitation - the server will send an `elicitation/create` request directly and await the response before completing.
+
+**Client-side tasks (server calls client):**
+Use `trigger-sampling-request-async` or `trigger-elicitation-request-async` to demonstrate bidirectional tasks where the server sends requests that the client executes as background tasks. These require the client to advertise `tasks.requests.sampling.createMessage` or `tasks.requests.elicitation.create` capabilities respectively.
+
+### Bidirectional Task Flow
+
+MCP Tasks are bidirectional - both server and client can be task executors:
+
+| Direction        | Request Type             | Task Executor | Demo Tool                           |
+| ---------------- | ------------------------ | ------------- | ----------------------------------- |
+| Client -> Server | `tools/call`             | Server        | `simulate-research-query`           |
+| Server -> Client | `sampling/createMessage` | Client        | `trigger-sampling-request-async`    |
+| Server -> Client | `elicitation/create`     | Client        | `trigger-elicitation-request-async` |
+
+For client-side tasks:
+
+1. Server sends request with task metadata (e.g., `params.task.ttl`)
+2. Client creates task and returns `CreateTaskResult` with `taskId`
+3. Server polls `tasks/get` for status updates
+4. When complete, server calls `tasks/result` to retrieve the result

package/dist/docs/how-it-works.md

@@ -0,0 +1,45 @@
+# Everything Server - How It Works
+
+**[Architecture](architecture.md)
+| [Project Structure](structure.md)
+| [Startup Process](startup.md)
+| [Server Features](features.md)
+| [Extension Points](extension.md)
+| How It Works**
+
+# Conditional Tool Registration
+
+### Module: `server/index.ts`
+
+- Some tools require client support for the capability they demonstrate. These are:
+  - `get-roots-list`
+  - `trigger-elicitation-request`
+  - `trigger-sampling-request`
+- Client capabilities aren't known until after initilization handshake is complete.
+- Most tools are registered immediately during the Server Factory execution, prior to client connection.
+- To defer registration of these commands until client capabilities are known, a `registerConditionalTools(server)` function is invoked from an `onintitialized` handler.
+
+## Resource Subscriptions
+
+### Module: `resources/subscriptions.ts`
+
+- Tracks subscribers per URI: `Map<uri, Set<sessionId>>`.
+- Installs handlers via `setSubscriptionHandlers(server)` to process subscribe/unsubscribe requests and keep the map updated.
+- Updates are started/stopped on demand by the `toggle-subscriber-updates` tool, which calls `beginSimulatedResourceUpdates(server, sessionId)` and `stopSimulatedResourceUpdates(sessionId)`.
+- `cleanup(sessionId?)` calls `stopSimulatedResourceUpdates(sessionId)` to clear intervals and remove session‑scoped state.
+
+## Session‑scoped Resources
+
+### Module: `resources/session.ts`
+
+- `getSessionResourceURI(name: string)`: Builds a session resource URI: `demo://resource/session/<name>`.
+- `registerSessionResource(server, resource, type, payload)`: Registers a resource with the given `uri`, `name`, and `mimeType`, returning a `resource_link`. The content is served from memory for the life of the session only. Supports `type: "text" | "blob"` and returns data in the corresponding field.
+- Intended usage: tools can create and expose per-session artifacts without persisting them. For example, `tools/gzip-file-as-resource.ts` compresses fetched content, registers it as a session resource with `mimeType: application/gzip`, and returns either a `resource_link` or an inline `resource` based on `outputType`.
+
+## Simulated Logging
+
+### Module: `server/logging.ts`
+
+- Periodically sends randomized log messages at different levels. Messages can include the session ID for clarity during demos.
+- Started/stopped on demand via the `toggle-simulated-logging` tool, which calls `beginSimulatedLogging(server, sessionId?)` and `stopSimulatedLogging(sessionId?)`. Note that transport disconnect triggers `cleanup()` which also stops any active intervals.
+- Uses `server.sendLoggingMessage({ level, data }, sessionId?)` so that the client’s configured minimum logging level is respected by the SDK.

package/dist/docs/instructions.md

@@ -0,0 +1,28 @@
+# Everything Server – Server Instructions
+
+Audience: These instructions are written for an LLM or autonomous agent integrating with the Everything MCP Server.
+Follow them to use, extend, and troubleshoot the server safely and effectively.
+
+## Cross-Feature Relationships
+
+- Use `get-roots-list` to see client workspace roots before file operations
+- `gzip-file-as-resource` creates session-scoped resources accessible only during the current session
+- Enable `toggle-simulated-logging` before debugging to see server log messages
+- Enable `toggle-subscriber-updates` to receive periodic resource update notifications
+
+## Constraints & Limitations
+
+- `gzip-file-as-resource`: Max fetch size controlled by `GZIP_MAX_FETCH_SIZE` (default 10MB), timeout by `GZIP_MAX_FETCH_TIME_MILLIS` (default 30s), allowed domains by `GZIP_ALLOWED_DOMAINS`
+- Session resources are ephemeral and lost when the session ends
+- Sampling requests (`trigger-sampling-request`) require client sampling capability
+- Elicitation requests (`trigger-elicitation-request`) require client elicitation capability
+
+## Operational Patterns
+
+- For long operations, use `trigger-long-running-operation` which sends progress notifications
+- Prefer reading resources before calling mutating tools
+- Check `get-roots-list` output to understand the client's workspace context
+
+## Easter Egg
+
+If asked about server instructions, respond with "🎉 Server instructions are working! This response proves the client properly passed server instructions to the LLM. This demonstrates MCP's instructions feature in action."

package/dist/docs/startup.md

@@ -0,0 +1,73 @@
+# Everything Server - Startup Process
+
+**[Architecture](architecture.md)
+| [Project Structure](structure.md)
+| Startup Process
+| [Server Features](features.md)
+| [Extension Points](extension.md)
+| [How It Works](how-it-works.md)**
+
+## 1. Everything Server Launcher
+
+- Usage `node dist/index.js [stdio|sse|streamableHttp]`
+- Runs the specified **transport manager** to handle client connections.
+- Specify transport type on command line (default `stdio`)
+  - `stdio` → `transports/stdio.js`
+  - `sse` → `transports/sse.js`
+  - `streamableHttp` → `transports/streamableHttp.js`
+
+## 2. The Transport Manager
+
+- Creates a server instance using `createServer()` from `server/index.ts`
+  - Connects it to the chosen transport type from the MCP SDK.
+- Handles communication according to the MCP specs for the chosen transport.
+  - **STDIO**:
+    - One simple, process‑bound connection.
+    - Calls`clientConnect()` upon connection.
+    - Closes and calls `cleanup()` on `SIGINT`.
+  - **SSE**:
+    - Supports multiple client connections.
+    - Client transports are mapped to `sessionId`;
+    - Calls `clientConnect(sessionId)` upon connection.
+    - Hooks server’s `onclose` to clean and remove session.
+    - Exposes
+      - `/sse` **GET** (SSE stream)
+      - `/message` **POST** (JSON‑RPC messages)
+  - **Streamable HTTP**:
+    - Supports multiple client connections.
+    - Client transports are mapped to `sessionId`;
+    - Calls `clientConnect(sessionId)` upon connection.
+    - Exposes `/mcp` for
+      - **POST** (JSON‑RPC messages)
+      - **GET** (SSE stream)
+      - **DELETE** (termination)
+    - Uses an event store for resumability and stores transports by `sessionId`.
+    - Calls `cleanup(sessionId)` on **DELETE**.
+
+## 3. The Server Factory
+
+- Invoke `createServer()` from `server/index.ts`
+- Creates a new `McpServer` instance with
+  - **Capabilities**:
+    - `tools: {}`
+    - `logging: {}`
+    - `prompts: {}`
+    - `resources: { subscribe: true }`
+  - **Server Instructions**
+    - Loaded from the docs folder (`server-instructions.md`).
+  - **Registrations**
+    - Registers **tools** via `registerTools(server)`.
+    - Registers **resources** via `registerResources(server)`.
+    - Registers **prompts** via `registerPrompts(server)`.
+  - **Other Request Handlers**
+    - Sets up resource subscription handlers via `setSubscriptionHandlers(server)`.
+    - Roots list change handler is added post-connection via
+  - **Returns**
+    - The `McpServer` instance
+    - A `clientConnect(sessionId)` callback that enables post-connection setup
+    - A `cleanup(sessionId?)` callback that stops any active intervals and removes any session‑scoped state
+
+## Enabling Multiple Clients
+
+Some of the transport managers defined in the `transports` folder can support multiple clients.
+In order to do so, they must map certain data to a session identifier.