Model Context Protocol
[Proposal] Action-level Pre-Execution Checklists for MCP Tool Definitions #817
Replies: 1 comment
|
After reviewing the MCP specification, it appears that the ideas I proposed are already covered. In particular, the input schema already provides required fields, and description can be used to express guidance and recommendations in natural language. One area that may still be worth considering is physical control. As MCP is increasingly being adopted for robotics (ROS/ROS2 bridges, robot arms, mobile robots, Home Assistant, and other real-world devices), there may be cases where guidance alone is not sufficient. It may be useful to have a standardized way to express conditions that make an operation non-executable rather than merely discouraged. On the other hand, this may also be solvable simply by encouraging providers to use stronger, unambiguous language in description. With that, I consider this discussion concluded. Thank you for the discussion. |
Uh oh!
There was an error while loading. Please reload this page.
Pre-submission Checklist
Your Idea
[Proposal] Action-level Pre-Execution Checklists for MCP Tool Definitions
Summary
MCP standardizes how Agents invoke Tools.
As autonomous Agents become more common, another question becomes equally important:
What must be confirmed before an action is executed?
When Tool Providers and Agent Developers are different organizations, this should no longer be left entirely to Agent-side reasoning. Providers should be able to explicitly declare the execution conditions their Actions require.
This proposal suggests introducing an optional Action-level Pre-Execution Checklist as a contract between Tool Providers and Agents.
Why this is needed
Until now, MCP has focused on invocation:
• input schema
• output schema
• transport
• protocol
That was sufficient when APIs were called directly.
Autonomous Agents introduce a different problem.
Even when an input schema is valid, an Agent still has to decide questions such as:
• Does the user really intend this action?
• Is additional confirmation required?
• Is essential information still missing?
• Should execution proceed now?
Today these decisions are usually implemented inside the Agent, often through model reasoning or proprietary logic.
Tool Providers currently have no standardized way to communicate these execution requirements.
The organizational boundary
When a Tool and an Agent are developed by the same organization, execution policy is simply an internal implementation detail.
MCP changes that assumption.
The Tool Provider understands the operational risks and intended usage of the Tool.
The Agent Developer decides when and how to execute it.
These responsibilities now belong to different organizations.
Without an explicit contract, every Agent must independently infer what should be confirmed before execution.
Proposal
Allow Tool Providers to optionally declare pre-execution requirements for each Action.
This is distinct from expressing runtime preconditions. The focus is on letting Providers explicitly declare what an Agent should verify before execution — so independent Agent implementations don't need to infer execution requirements on their own.
Rather than prescribing a specific implementation, MCP should provide a standardized way for Providers to communicate:
• what should be confirmed before execution;
• why confirmation is required;
• what information must come from the user before execution;
• whether the confirmation is mandatory or advisory.
The representation itself should remain flexible.
It may be natural language, structured metadata, schemas, or future extensions.
The goal is not to standardize Agent implementations.
The goal is to standardize how execution requirements are communicated across organizational boundaries.
The checklist defines explicit execution requirements. Together, these requirements form an execution contract between Tool Providers and Agent implementations. The proposal does not prescribe how Agents should implement these checks; it only standardizes how Providers communicate them across organizational boundaries.
Responsibility boundaries
Once execution requirements become explicit, responsibility also becomes clearer.
• If the Provider does not define necessary execution requirements, responsibility belongs to the Provider.
• If the Provider defines them but the Agent ignores them, responsibility belongs to the Agent.
• If the Agent invents missing information instead of obtaining explicit user confirmation, the execution should not be considered user-approved.
This is no longer simple input validation.
It becomes a shared execution contract between independent organizations.
Open Questions
• Should pre-execution requirements belong to individual Actions or entire Tools?
My view: Action-level. Different Actions under the same Tool often carry very different risk profiles (e.g. read_file vs delete_file), so a Tool-level declaration would be too coarse to be useful.
• Is natural language sufficient, or should structured fields also be standardized?
My view: natural language. Providers vary widely in their internal rules, and forcing a rigid structured schema would be hard to standardize across them. Natural language is easier for Providers to write and for Agents (LLMs) to read directly.
• Should this extend the existing description field, or introduce a dedicated field?
My view: extend description. This avoids introducing a new field Agents must separately learn to parse, and keeps the checklist naturally colocated with the Action's existing documentation.
• How should mandatory requirements be distinguished from recommendations?
Open — feedback welcome.
This proposal extends the ideas discussed in:
If unsure, ask. Never guess. — AI Agent Pre-Execution Checklist
This proposal asks a different question:
How can Tool Providers communicate those execution requirements to independent Agent implementations through MCP?
Scope
All reactions