feat(mcp): support MCP 2025-11-25 tasks/call for long-running tool requests

[bug-ops]

Description

MCP specification 2025-11-25 introduces a Tasks primitive that allows any tool call to be augmented with an asynchronous task ID. The client can poll tasks/result for the outcome instead of waiting synchronously. For an LSP bridge like mcpls this is relevant for operations that may time out in large workspaces: find_references, rename, and workspace-wide diagnostics can take several seconds against rust-analyzer on a large monorepo.

rmcp 1.5.0 already models the required types (TasksCapability, ToolsTaskCapability, GetTaskResultRequest, CancelTaskResult) and the protocol version defaults to V_2025_11_25.

What Would Change

• ServerCapabilities advertised by mcpls would include tasks.requests.tools.call = {}
• Tool handlers that perform long LSP round-trips would return a CreateTaskResult (task ID) instead of blocking
• A background tokio task would await the LSP response and store the result
• The client can call tasks/result with the task ID to retrieve it
• tasks/cancel would abort the underlying LSP request

Affected Tools (candidates)

Tool	LSP method	Typical latency
find_references	textDocument/references	1–10 s on large repos
rename_symbol	textDocument/rename	2–15 s (workspace-wide)
get_diagnostics	polling cache	fast; lower priority
get_completions	textDocument/completion	0.5–2 s; borderline

Prerequisite

The MCP client (e.g., Claude Desktop) must also advertise tasks capability. Without mutual capability negotiation, this feature silently degrades — task responses would be ignored. This makes implementation risk low.

Environment

• rmcp: 1.5.0 (already includes task model types)
• MCP spec: 2025-11-25 (ProtocolVersion::LATEST in rmcp)
• Relevant rmcp types: TasksCapability, ToolsTaskCapability, GetTaskResultParams, CreateTaskResult

References

• MCP 2025-11-25 changelog: https://modelcontextprotocol.io/specification/2025-11-25/changelog
• rmcp TasksCapability: src/model/capabilities.rs