[proposal] Add sensitive flag for the Tool #176
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I think the Tool Annotations in #185 would provide this in a generic fashion? I think the number of properties on the Tool schema could easily explode if this is not handled in a generic way, as there are numerous perfectly use cases similar to this one, but with different properties. |
|
Closing in favor of #185, but thank you for submitting this! Sorry for the delay—we're still catching up on our backlog. |
|
Hey, sorry for the late response. I wasn't aware of those initiatives. I think the Tool Annotations feature might be enough to solve this use case. Thanks for taking a look and providing feedback. |
jspahrsummers
pushed a commit
that referenced
this pull request
Apr 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces a new
sensitiveflag for tools in the MCP specification. With this update, tools can now indicate if they perform sensitive operations that require explicit user confirmation before invocation. The change is applied across the documentation and the JSON schema, as well as the TypeScript definitions.Motivation and Context
The motivation behind this update is to enhance security and trust when tools are invoked. By marking a tool as sensitive, clients can be alerted to always present a confirmation prompt to the user. This helps mitigate risks associated with sensitive operations by ensuring a human is in the loop before any critical action is performed.
How Has This Been Tested?
Since this change is a non-breaking update to the specification and only affects the documentation and schema definitions, no runtime tests were necessary.
Breaking Changes
This change is non-breaking:
• Existing tools without the sensitive flag will continue to operate with the default behavior (i.e., treated as non-sensitive).
• Clients may choose to leverage the new flag to enforce additional UI confirmation, but backward compatibility is maintained.
Types of changes
Checklist
Additional context
At Crunchloop, we are implementing MCP servers to enable our customers’ internal teams to interact with their custom platforms both efficiently and safely. A common concern that arises is how to incorporate a non-deterministic check that requires explicit operator confirmation before executing a given tool. While our current solution uses a carefully crafted system prompt to inform the LLM about the necessary security measures, the inherent non-determinism of LLMs sometimes falls short in ensuring that sensitive operations receive the proper human confirmation. With the new sensitive flag, we provide a clear, protocol-level signal that mandates explicit confirmation for sensitive operations, thereby reinforcing safety and reducing reliance on LLM behavior alone.
While researching similar discussions, I discovered a previous discussion on this topic (Discussion #71) that, despite its relevance, didn’t gain significant traction. Initially, I considered introducing a confirmation flag to address the issue. However, after further reflection, I decided that a sensitive flag better conveys the intent by explicitly indicating when a tool performs operations that require heightened security measures.