fix(tasks): expose execution.taskSupport on tools

[LucaButBoring]

Exposes execution.taskSupport on tools during tools/list.

Motivation and Context

To enable servers to heterogenously expose task and non-task tools, there's an execution.taskSupport field that was added to the tool schema from tools/list (described here and here). Without this field, clients are unable to determine if a tool supports tasks or not, forcing all-or-nothing support.

How Has This Been Tested?

New unit tests; spot-checked against a test server.

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 Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Fixes #633.

[Copilot]

Pull request overview

This PR adds support for exposing execution.taskSupport on tools during tools/list responses, enabling servers to heterogeneously expose task and non-task tools. This allows clients to determine whether a tool supports task-based invocation without requiring all-or-nothing support across all tools.

Changes:

• Added TaskSupport enum with three variants: Forbidden (default), Optional, and Required
• Added ToolExecution struct containing task support configuration
• Updated Tool struct to include optional execution field
• Extended tool macro to support execution attribute with task_support parameter

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
crates/rmcp/src/model/tool.rs	Added TaskSupport enum, ToolExecution struct, and execution field to Tool with builder methods
crates/rmcp-macros/src/tool.rs	Extended tool macro to parse and generate execution configuration from attributes
examples/servers/src/sampling_stdio.rs	Updated example to include execution: None in tool definition
crates/rmcp/tests/test_deserialization/tool_list_result.json	Added test case with execution.taskSupport set to "optional"
crates/rmcp/tests/test_message_schema/server_json_rpc_message_schema.json	Added JSON schema definitions for TaskSupport and ToolExecution
crates/rmcp/tests/test_message_schema/server_json_rpc_message_schema_current.json	Added JSON schema definitions for TaskSupport and ToolExecution (current version)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jokemanfire]

Could you add some unit test? Thanks . and pls ensure this situation has been included
If execution.taskSupport is "required", clients MUST invoke the tool as a task. Servers MUST return a -32601 (Method not found) error if a client does not attempt to do so.

[LucaButBoring]

@jokemanfire Added server-side validation and tests for it (using the new client logic). I avoided implementing the autoselection logic on the client because it implies a union response, which would be a breaking change - or, we could have a new client method to do the selection automatically and only expect the existing one to fail if it's misconfigured (which is what I do in the other SDKs). That would increase the scope of this fix, though.

[jokemanfire]

LGTM

[alexhancock]

Thanks @LucaButBoring