Loading ToolBench
MCP server that detects AI fix loops and forces course correction
The server defines 4 tools with clear, detailed descriptions and well-structured schemas. Tool names follow verb_noun convention (log_fix_attempt, check_loop_status, get_escape_strategies, resolve_loop). All parameters have type definitions and descriptions. However, output schemas are not formally documented, responses are JSON-stringified text rather than structured tool output. Error handling is minimal; no recovery guidance or categorization. The domain is specialized (loop detection) and well-executed within that scope, but lacks production-grade error resilience.
Read-only status check — see if you're currently in a fix loop WITHOUT logging a new attempt. Use this BEFORE starting a complex multi-file fix to see if you should change approach first. Also useful for decision-making: "Am I already in a loop? Should I try a different strategy?" Returns the current escalation level, attempt count, and strategies if in a loop. Does NOT increment any counters.
Get concrete, actionable strategies to escape a fix loop. Each strategy includes a title, specific steps to execute, and reasoning for why it helps. Strategies are matched to your error category (syntax, type, import, build, test, runtime) and escalation level. Higher levels get more aggressive strategies (e.g., CRITICAL includes "revert everything" and "ask the user"). Call this when you want strategy suggestions without logging a new attempt — for example, when planning your next move after a NUDGE alert.
MANDATORY: Call this EVERY TIME you attempt to fix an error — after every code change, config edit, install command, or any action intended to resolve an error. This tool tracks your attempts and uses fingerprinting + similarity analysis to detect when you're stuck in a loop (repeating the same failing approach with minor variations). HOW IT WORKS: The tool normalizes your error message into a fingerprint and compares your fix description against previous attempts. If you've tried the same error 3+ times, it escalates with increasing urgency (NUDGE → WARNING → CRITICAL) and provides concrete escape strategies. WHAT TO DO WITH THE RESPONSE: - "NONE": Continue normally, the tool is just tracking. - "NUDGE": You're starting to loop. Change your approach NOW — read the strategies. - "WARNING": Confirmed loop. STOP coding. Revert changes. Follow the strategies. - "CRITICAL": STOP IMMEDIATELY. Revert everything. Ask the user for help. IMPORTANT: The quality of detection depends on your fix_description. Be specific about WHAT you changed and WHY — not just "fixed the error". Example: "Changed import from relative './utils' to absolute '@/lib/utils' because tsconfig paths are configured for @ alias".
Output schemas not formally documented. Tools return JSON-stringified text (type: 'text') rather than structured objects. LLMs cannot parse response fields reliably without explicit schema documentation.
No error handling or recovery guidance. Tools do not validate inputs (e.g., session_id format, error_message length) or return actionable error messages. Failures will produce generic exceptions.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). check_loop_status and get_escape_strategies are read-only; resolve_loop is destructive. Annotations help LLMs reason about side effects and retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Call this when the error you were working on is FIXED — the build passes, the test passes, or the runtime error is gone. This resets all loop tracking counters for the session so the next error starts with a clean slate. IMPORTANT: Always call this after resolving an error, especially one you were looping on. If you skip this, the next unrelated error may trigger false loop alerts because the stale attempt history is still active.
Parameter descriptions lack format/constraint details. 'error_message' should specify minimum length, expected structure (error type + body + stack trace). 'session_id' should document format (alphanumeric, max length). Vague constraints invite invalid LLM input.
resolve_loop lacks confirmation/dry-run pattern. Calling it resets all loop tracking, a destructive operation. No confirmation step or preview of what will be cleared. Agents could accidentally reset tracking mid-session.