Passive loop detection MCP server for AI coding agents. Detects tool-call repetition, semantic similarity loops, pattern cycles, and context budget exhaustion — no agent initiative required.
Anti-Loop Guard provides 4 tools with clear, domain-specific descriptions (avg 156 chars). Tool names are action-oriented (log_, check_, session_, reset_). However, input schemas lack comprehensive parameter descriptions, most params have minimal or no guidance on expected formats, ranges, or constraints. The 'args' parameter in log_tool_call is typed as 'object' with no schema constraints, inviting arbitrary input. Output schemas are not documented. Error handling is implicit (no recovery guidance in descriptions). Resources are present but tool composition is narrow (all read-only except reset_session). Naming is clear but parameter documentation falls short of production baseline (100% of A+ tools have param descriptions).
Explicitly check whether the agent is currently in a loop. Returns detection result with pattern type, confidence, and a recommendation.
Record a tool call for loop detection, or check loop status. The PreToolUse hook records every call passively — this call only checks status. Call this after every tool invocation. Returns the current loop detection status.
Reset all tracking state. Use when starting a fresh task or after clearing context.
Get a full session health report: tool call count, context budget risk level, repetition rate, and degradation indicators based on published LLM research.
Parameter 'args' in log_tool_call is typed as unconstrained 'object' with no schema validation, format guidance, or examples. LLMs cannot infer what structure is expected.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., does check_repetition return confidence, pattern_type, recommendation as separate fields or nested?).
Parameter descriptions are minimal or absent. 'tool_name' has no guidance on format (e.g., 'Name of the tool that was called (e.g. Bash, Read, Edit)' is an example, not a constraint). 'tool_use_id' lacks clarity on when it's required vs optional.
No error handling guidance. If a tool call fails (e.g., invalid tool_name, malformed args), descriptions do not explain what the LLM should do next or how to self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
reset_session has no confirmation or dry-run pattern. Destructive operations should support a confirmation step to prevent accidental state loss.