Skip to content

fix(tasks): ignore task metadata when tasks are not declared - #355

Open
mcollina wants to merge 1 commit into
mainfrom
fix/339-ignore-task-when-tasks-disabled
Open

mcollina wants to merge 1 commit into
mainfrom
fix/339-ignore-task-when-tasks-disabled

Conversation

@mcollina

Copy link
Copy Markdown
Member

Summary

With tasks disabled (no enableTasks, so no task store), a 2025-11-25 tools/call that carried task was refused with -32601 "Tasks are not enabled on this server". A tool marked taskSupport: 'required' could never be called, and tools/list still advertised execution.taskSupport even though capabilities.tasks was not declared.

The 2025-11-25 tasks spec (spec/tasks.md) says:

Receivers that do not declare the task capability for a request type MUST process requests of that type normally, ignoring any task-augmentation metadata if present.

execution.taskSupport is defined as "a fine-grained layer in addition to capabilities", so without tasks.requests.tools.call it does not apply.

Fix (src/handlers.ts)

  • A new helper, tasksDeclaredTo(dependencies), returns true when a task store exists and the negotiated revision supports tasks, which is exactly when tasks.requests.tools.call was declared to this client.
  • handleToolsCall: when tasks are not declared, task is ignored. Its ttl is not validated and the call never takes the task path. resolveTaskAugmentation is skipped, so neither the forbidden nor the required rule applies. The older-revision case already ignored task, and it now goes through the same predicate. One side effect: a required tool called by a pre-2025-11-25 client on a server with tasks enabled now runs normally instead of returning -32601. That client was never told about tasks, and trimDefinitionToRevision already strips execution from its tools/list, so this is the same spec rule.
  • handleToolsList: when tasks are not declared, execution.taskSupport is removed, and execution is dropped if nothing else is left in it.
  • The README notes that taskSupport has no effect without enableTasks.

Not changed: the in-process app.mcpCallTool() API still refuses required tools with task-required. It is a programmatic entry point, not the protocol, and test/mcp-call-tool.test.ts pins that behaviour.

Tests

  • test/tasks.test.ts, new suite "task metadata with tasks disabled": a tools/call with task: { ttl: 5000 } returns the tool result. task is ignored on a tool without task support and with an invalid ttl. A required tool can be called directly. tools/list carries no taskSupport.
  • test/revision-behavior.test.ts: a 2025-03-26 client can call a required tool on a server with tasks enabled, and a 2025-11-25 client still gets -32601.
  • All new tests failed before the fix. npm run lint, npm run typecheck and the full npm run test pass (771/771).

Fixes #339

🤖 Generated with Claude Code

https://claude.ai/code/session_01LmhsFjk8W96X2PvmShmDm9

With tasks disabled, a 2025-11-25 tools/call carrying `task` was refused
with -32601, a `taskSupport: 'required'` tool could never be called, and
tools/list still advertised `execution.taskSupport`. The spec requires a
receiver that does not declare the task capability for a request type to
process it normally, ignoring task metadata.

When tasks are not declared to the client (no task store, or a revision
before 2025-11-25), tools/call now ignores `task` and skips the
taskSupport checks, and tools/list omits `execution.taskSupport`.

Fixes #339

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LmhsFjk8W96X2PvmShmDm9

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

With tasks disabled, a 2025-11-25 tools/call carrying task is refused instead of run normally

1 participant