An MCP server to inject auto-approve MCP functionality into Claude Desktop
Claude Auto-Approve MCP has 8 tools with clear names following verb_noun conventions (inject_autoapprove, get_trusted_tools, add_trusted_tool, etc.). However, the server suffers from significant gaps in description completeness and schema documentation. All tools have basic descriptions, but most are terse (10-50 characters) and lack context about when to use them, prerequisites, or what they return. Parameter descriptions exist but are minimal. No output schemas are documented, the code shows tool registration but no visible return type documentation. Error handling is absent from descriptions; there is no guidance on recovery, retryable vs fatal errors, or what the LLM should do if a tool fails. The definitions are functional but would not pass code review for production agent use. Naming is strong; descriptions and schemas are weak.
Adds a tool to the blocked list, preventing it from auto-execution.
Adds a tool to the auto-approve trusted list.
Gets the current status of the auto-approve injection.
Retrieves a list of tools that are currently blocked from auto-execution.
Retrieves a list of tools that are currently approved for auto-execution.
Injects the auto-approve script into Claude Desktop and restarts the process.
Removes a tool from the blocked list, allowing it to be auto-executed.
Removes a tool from the auto-approve trusted list.
No output schemas documented for any tool. LLMs cannot determine response structure, field names, or data types. This violates pattern:tool and forces LLMs to infer behavior, leading to failed chains.
Destructive operations (inject_autoapprove, remove_trusted_tool, remove_blocked_tool) lack explicit warnings in descriptions and no confirmation/dry-run support. Violates pattern:confirmation-request and pattern:command-tool. Agents could cause harm without operator oversight.
Idempotence and error handling not documented. Tools like add_trusted_tool do not specify whether calling twice with the same input is safe, or what happens if the tool is already on the list. Agents cannot safely retry without duplicating side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Descriptions are terse (35 - 61 chars) and lack context. They answer 'what' but not 'when' or 'why'. No guidance on dependencies, preconditions, or which tool to call in a multi-step workflow. LLMs cannot make informed tool selection decisions.
No error handling guidance. Descriptions do not explain what can go wrong, when errors are retryable, or how the LLM should recover. Agents will fail silently when tools error.