Skip to content

Conversation

@chrisguidry
Copy link
Collaborator

The base Tool class now has an optional execution field for storing task execution metadata (SEP-1686). This lets gateways/proxies preserve execution info when forwarding tools from backends - previously this metadata was lost because Tool had no way to store it.

When a gateway receives tools from a backend with execution metadata (e.g., taskSupport: "optional"), it can now store that in a Tool object and have it survive the round-trip through to_mcp_tool().

# Gateway can now preserve execution metadata from backends
tool = Tool(
    name="backend_tool",
    parameters={...},
    execution=ToolExecution(taskSupport="optional"),
)

# Metadata preserved when converting back to MCP
mcp_tool = tool.to_mcp_tool()
assert mcp_tool.execution.taskSupport == "optional"

FunctionTool continues to derive execution from task_config as before - this only affects the base Tool class.

🤖 Generated with Claude Code

The base Tool class now has an optional `execution` field for storing
task execution metadata (SEP-1686). This lets gateways/proxies preserve
execution info when forwarding tools from backends - previously this
metadata was lost because Tool had no way to store it.

FunctionTool continues to derive execution from task_config as before.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>
@marvin-context-protocol marvin-context-protocol bot added enhancement Improvement to existing functionality. For issues and smaller PR improvements. server Related to FastMCP server implementation or server-side functionality. labels Dec 8, 2025
@chrisguidry chrisguidry merged commit 515e8e8 into main Dec 8, 2025
11 of 12 checks passed
@chrisguidry chrisguidry deleted the tool-execution-field branch December 8, 2025 22:11
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 8, 2025

Walkthrough

This change adds an optional execution field to the Tool class in src/fastmcp/tools/tool.py to carry task execution configuration settings. The field is typed as ToolExecution | None and defaults to None. During Tool to MCP Tool conversion, the implementation now preserves the tool's execution value as a default when no override is explicitly provided, using execution=overrides.get("execution", self.execution) in the conversion logic.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The pull request title accurately and concisely describes the main change: adding an execution field to the base Tool class, which is the primary modification in the changeset.
Description check ✅ Passed The description provides clear context about the change (storing task execution metadata), includes a practical example, notes the scope limitation to the base Tool class, and discloses the use of Claude Code for generation. However, it does not include the required Contributors/Review checklists from the template.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch tool-execution-field

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
src/fastmcp/tools/tool.py (1)

136-193: Execution metadata field and propagation logic look correct; consider cloning behavior

The new execution field on Tool and its propagation via execution=overrides.get("execution", self.execution) into MCPTool look solid: typing is appropriate (ToolExecution | None), precedence is consistent with other fields (overrides win over the instance default), and FunctionTool.to_mcp_tool still correctly respects explicit execution overrides while deriving execution from task_config otherwise.

One optional thing to double‑check: any helper paths that wrap/clone tools (e.g., via Tool.from_tool / TransformedTool.from_tool or similar) should also preserve the execution value from the source tool so this metadata isn’t silently dropped in those flows.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 659ec38 and 17520ec.

⛔ Files ignored due to path filters (1)
  • tests/tools/test_tool.py is excluded by none and included by none
📒 Files selected for processing (1)
  • src/fastmcp/tools/tool.py (2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/**/*.py

📄 CodeRabbit inference engine (AGENTS.md)

src/**/*.py: Python source code must use Python ≥3.10 with full type annotations
Never use bare except - be specific with exception types
Prioritize readable, understandable code - clarity over cleverness; avoid obfuscated or confusing patterns even if shorter
Follow existing patterns and maintain consistency in code organization and style

Files:

  • src/fastmcp/tools/tool.py
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
  • GitHub Check: label-issue-or-pr
  • GitHub Check: Run tests with lowest-direct dependencies
  • GitHub Check: Run tests: Python 3.10 on windows-latest
  • GitHub Check: Run tests: Python 3.10 on ubuntu-latest

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

Labels

enhancement Improvement to existing functionality. For issues and smaller PR improvements. server Related to FastMCP server implementation or server-side functionality.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants