Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Feature/add enable disable methods tools #728

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: main
Choose a base branch
Loading
from

Conversation

davila7
Copy link

@davila7 davila7 commented May 15, 2025

Added the ability to dynamically enable and disable tools at runtime with client notifications.

Motivation and Context

This change allows developers to temporarily restrict access to specific tools without removing them from the tool manager. This is useful for implementing feature flags, managing resource availability, or controlling access to functionality based on runtime conditions.

How Has This Been Tested?

  • Added unit tests for enabling/disabling tools
  • Verified that disabled tools don't appear in tool listings and cannot be called
  • Tested re-enabling previously disabled tools

Breaking Changes

The tool list now includes the enabled state of each tool. However, all tools are initialized with enabled=True by default, maintaining backward compatibility with existing code.

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

@@ -72,4 +72,7 @@ async def call_tool(
if not tool:
raise ToolError(f"Unknown tool: {name}")

if not tool.enabled:

Choose a reason for hiding this comment

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

Should we add similar checks in call_tool() and get_tool() as well?

Copy link
Author

Choose a reason for hiding this comment

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

For call_tool() we already have the necessary validation checking if the tool is enabled.

And for get_tool(), I think we don't need to add this validation. We retrieve in get_tool() and validate in call_tool() where the tool is actually used.
This keeps the code cleaner and lets us access disabled tools when needed (for inspection, etc).

Copy link

@bzsurbhi bzsurbhi left a comment

Choose a reason for hiding this comment

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

I believe it needs a spec change as well. Do we already have a PR for it?

@davila7
Copy link
Author

davila7 commented May 20, 2025

I believe it needs a spec change as well. Do we already have a PR for it?

I've added it to the README in this commit:
fd71115#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R253

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.

2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.