Repository navigation
Description
What is the problem this feature would solve?
The McpServer module currently supports protocol versions up to 2025-06-18. The MCP spec released 2025-11-25 with several additions:
Major features:
- Tasks primitive (experimental) — durable async requests with polling and deferred result retrieval (SEP-1686)
- Icons for tools, resources, resource templates, and prompts (SEP-973)
- Tool calling support in sampling via
toolsandtoolChoice(SEP-1577) - Elicitation improvements — default values for primitives (SEP-1034), titled/multi-select enums (SEP-1330), URL mode (SEP-1036)
- Input validation errors as Tool Execution Errors for model self-correction (SEP-1303)
Auth/OAuth:
- OAuth Client ID Metadata Documents (SEP-991)
- OAuth client-credentials for M2M flows (SEP-1046)
- OpenID Connect Discovery 1.0 (PR chore(deps-dev): bump chalk from 4.1.1 to 4.1.2 #797)
- Incremental scope consent via
WWW-Authenticate(SEP-835) - RFC 9728-aligned Protected Resource Metadata discovery (SEP-985)
Protocol-level:
- Decoupled request payloads from RPC method definitions (SEP-1319)
- JSON Schema 2020-12 as default dialect (SEP-1613)
- Polling SSE streams with server-initiated disconnection (SEP-1699)
Full changelog: https://modelcontextprotocol.io/specification/2025-11-25/changelog
How this helps my use case
I'm building a CRM exposed entirely through MCP — 7 toolkits, 3 resources, and 4 prompts (company research, daily briefing, proposal draft, follow-ups). Here's what each feature unlocks:
Tasks — My current tools are fast DB queries, but I'm adding AgentMail integration and Firecrawl-based company research as tools. Those are inherently async and would benefit from returning a handle immediately with progress updates instead of blocking the connection.
Icons — With 7 tool groups (companies, contacts, interactions, tasks, documents, pages, pipeline) plus resources and prompts, icons would help users navigate the tool list in MCP clients like Claude Desktop.
Input validation as tool errors — My tool handlers currently use Effect.orDie, which turns bad input into protocol-level crashes. The spec change (SEP-1303) says these should be tool execution errors so the model can self-correct and retry with valid parameters — a better fit for CRM tools where the model often passes a wrong slug or ID.
OAuth — I currently authenticate MCP via better-auth session cookies in custom middleware. Spec-level OAuth would let third-party MCP clients connect without knowing my session format.
The elicitation enhancements (default values, titled enums, multi-select) would also be a nice improvement for tools like create_company that have many optional fields — though basic elicitation already works on 2025-06-18.
What alternatives have you considered?
Staying on 2025-06-18 works since clients negotiate down, but as MCP clients adopt 2025-11-25 features, Effect servers can't advertise them.
Activity
tim-smart commentedon Jul 28, 2026
Automated message: Effect v3 is now under a feature freeze and is now only considering bug fixes.
If this issue is still relevant for v4, then feel free to reopen :)
guillempuche commentedon Jul 28, 2026
Reopening against v4, as suggested.
This is still relevant, and v4
mainhas actually made it more tractable since I filed it:McpServernow routes through a pluggable protocol registry, with per-session protocol selection andmcp-protocol-versionheader negotiation. ButMcpProtocol.tsstill exports a single adapter:So the concrete ask is now narrower than the original body: add a
McpProtocol.v2025_11_25adapter alongside the existing one, wideningProtocolVersionto the union, plus theMcpSchemaadditions the newer spec needs (tasks, icons, samplingtools/toolChoice, the elicitation enhancements, and SEP-1303 input-validation-as-tool-execution-error).The feature list in the original description still applies — full changelog: https://modelcontextprotocol.io/specification/2025-11-25/changelog
Happy to take a first pass at the adapter if that direction is welcome.