Related to #114, but at a different grain.
Is your feature request related to a problem? Please describe.
Let's imagine I have an API with two endpoints:
GET /users/: lists usersPUT /users/<id>: edits a user's attributes
I want my users to install a single MCP server to handle connections to my API, with multiple tools.
As a user, when I install this MCP server, my agent/chatbot app might ask for initial confirmation. This is all fine and good for the GET endpoint, but as a user I also want to manually be able to audit and approve any changes the agent decides to make to the PUT one.
Describe the solution you'd like
Add an optional per-action flag or marker, to indicate risk level of the action performed.
It would then be up to client implementations to handle what to do with this information.
For risky actions, the docs can prescribe that use in a chatbot setting would be to let the user confirm any actions taken.
Describe alternatives you've considered
I believe having a server-grain risk level is too high, as I imagine the standard will be to have multiple tool actions available within a single MCP server connection.
Related to #114, but at a different grain.
Is your feature request related to a problem? Please describe.
Let's imagine I have an API with two endpoints:
GET /users/: lists usersPUT /users/<id>: edits a user's attributesI want my users to install a single MCP server to handle connections to my API, with multiple tools.
As a user, when I install this MCP server, my agent/chatbot app might ask for initial confirmation. This is all fine and good for the
GETendpoint, but as a user I also want to manually be able to audit and approve any changes the agent decides to make to thePUTone.Describe the solution you'd like
Add an optional per-action flag or marker, to indicate risk level of the action performed.
It would then be up to client implementations to handle what to do with this information.
For risky actions, the docs can prescribe that use in a chatbot setting would be to let the user confirm any actions taken.
Describe alternatives you've considered
I believe having a server-grain risk level is too high, as I imagine the standard will be to have multiple tool actions available within a single MCP server connection.