Record an explicit approval decision to override a pending requirement. Specify the approval ID, decision maker, and optional reference to log the outcome.
Record an explicit approval decision. Authentication remains the MCP host's responsibility.
| Name | Required | Description | Default |
|---|---|---|---|
| decided_by | Yes | ||
| approval_id | Yes | ||
| decision_ref | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Authentication remains the MCP host's responsibility.' It does not disclose side effects, state changes, irreversibility, idempotency, or what happens to the associated approval record. This is a thin amount of behavioral context, though it does at least clarify that the tool does not handle authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the core purpose in the first sentence. The authentication note is a real piece of context and not filler, so there is no wasted wording; it is concise, though very sparse overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation tool with no annotations, an agent still needs to know when to use it, what the optional decision_ref means, and what consequence recording an approval has. The output schema exists and covers return shape, but the missing usage guidance and parameter semantics leave the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema description coverage is 0%, and the description does not explain approval_id, decided_by, or decision_ref. The phrase 'Record an explicit approval decision' loosely implies a decision identifier and decider, but decision_ref remains entirely unexplained, so the description does not compensate for the missing schema parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Record') and the resource ('an explicit approval decision'), so an agent can tell this tool records approval decisions. It does not explicitly differentiate itself from sibling tools like reject_override or request_override, though the phrase 'approval decision' and the tool name make the general intent fairly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use approve_override versus reject_override, request_override or list_approvals. The only additional sentence is about authentication responsibility, which is a prerequisite, not a usage condition or alternative selection guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.