Skip to content

feat(everything): add SEP-1686 Tasks support #3193

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Draft
olaservo wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

feat(everything): add SEP-1686 Tasks support #3193

olaservo wants to merge 2 commits into from
+872 −1

Conversation

@olaservo
Copy link
Member

@olaservo olaservo commented Jan 9, 2026 •
edited
Loading

Description

Add support for SEP-1686 Tasks to the Everything Server. This enables the server to demonstrate MCP's task-based execution pattern for long-running operations, including task lifecycle management, status polling, and the input_required flow.

This PR demonstrates both directions of MCP Tasks:

  • Client → Server: Server executes tool calls as background tasks
  • Server → Client: Client executes sampling/elicitation requests as background tasks

Server Details

  • Server: everything
  • Changes to: tools, server capabilities, documentation

Motivation and Context

This addresses issue #3037 - adding Tasks support to the Everything Server as part of the SEP-1686 implementation.

The Everything Server serves as a reference implementation demonstrating MCP capabilities. With Tasks now part of the MCP specification (2025-11-25 schema), the Everything Server should demonstrate this feature to help client developers understand and test their Tasks implementations.

Server-side Tasks (Client calls Server)

  • Task creation via tools/call with task parameter
  • Status polling via tasks/get with statusMessage updates
  • Result retrieval via tasks/result
  • The input_required status flow with elicitation side-channel
  • Task TTL and cleanup

Client-side Tasks (Server calls Client) - Bidirectional

  • Server sends sampling/createMessage with task metadata
  • Client creates task and returns CreateTaskResult
  • Server polls tasks/get for status updates
  • Server retrieves result via tasks/result
  • Same pattern for elicitation/create

How Has This Been Tested?

  • Tested bidirectional task flow with ad-hoc MCP client library
  • Server-side tasks (simulate-research-query) still need testing with Inspector
  • Client-side tasks (trigger-sampling-request-async, trigger-elicitation-request-async) need Inspector with task support

TODO: Full testing with Inspector once it supports Tasks capability.

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 (TODO: 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

Additional context

Files Changed

  1. src/everything/server/index.ts

    • Import InMemoryTaskStore and InMemoryTaskMessageQueue from SDK experimental
    • Create task store and message queue instances
    • Add tasks capability with list, cancel, and requests.tools.call
    • Add cleanup call for task store timers

  2. src/everything/tools/simulate-research-query.ts (new)

    • Demonstrates experimental.tasks.registerToolTask() API
    • Simulates a multi-stage research operation with progress updates
    • Shows input_required flow when ambiguous: true is passed
    • Uses elicitation to gather clarification from user

  3. src/everything/tools/trigger-sampling-request-async.ts (new)

    • Demonstrates bidirectional tasks (server → client)
    • Sends sampling request with task metadata
    • Polls client's tasks/get for status
    • Retrieves LLM result via tasks/result
    • Requires client to support tasks.requests.sampling.createMessage

  4. src/everything/tools/trigger-elicitation-request-async.ts (new)

    • Same pattern as sampling for elicitation requests
    • Useful when user input may take time
    • Requires client to support tasks.requests.elicitation.create

  5. src/everything/tools/index.ts

    • Import and register all new task-related tools

  6. src/everything/docs/features.md

    • Added new tools to Tools section
    • Added "Tasks (SEP-1686)" section documenting both task directions
    • Added bidirectional task flow table and explanation

Bidirectional Task Flow

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

Related PRs/Issues

@olaservo
feat(everything): add SEP-1686 Tasks support
0208e93 
- Add tasks capability with list, cancel, and requests.tools.call
- Add InMemoryTaskStore and InMemoryTaskMessageQueue from SDK experimental
- Add simulate-research-query tool demonstrating task lifecycle
- Task demonstrates working -> input_required -> completed status flow
- Uses elicitation for ambiguous queries when client supports it

Closes modelcontextprotocol#3037

🦉 Generated with [Claude Code](https://claude.ai/code)
@olaservo olaservo requested a review from cliffhall January 9, 2026 13:55
@olaservo @claude
feat: add async sampling and elicitation tools
9d863fb 
Add tools that demonstrate bidirectional MCP tasks where the server
sends requests to the client for async execution:

- trigger-sampling-request-async: Send sampling request with task
  params, client creates task and executes LLM call in background,
  server polls for completion and retrieves result

- trigger-elicitation-request-async: Same pattern for user input,
  useful when user may take time to fill out forms

Both tools:
- Check client capabilities (tasks.requests.sampling/elicitation)
- Accept both CreateTaskResult and direct result responses
- Poll tasks/get for status updates
- Fetch final result via tasks/result

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cliffhall cliffhall Awaiting requested review from cliffhall

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Add Support for SEP-1686: Tasks to Everything Server

1 participant

@olaservo