Loading ToolBench
MCP server for mjloop - a project loop management system with planning, story tracking, quality verification, and feature management capabilities
mjloop exposes 5 tools with consistent naming (verb_noun pattern: mjloop_*) and reasonable descriptions (100-200 chars). All tools have input schemas with type definitions. However, parameter descriptions are sparse or generic ('Project root. Defaults to CLAUDE_PROJECT_DIR or cwd.' repeated verbatim across all tools), and output schemas are entirely undocumented. Error handling is present but minimal, the guard() wrapper catches exceptions and returns isError=true with message text, but does not categorize errors or guide recovery. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (WRITE vs READ_ONLY). Parameter relationships (e.g., mjloop_run_start's feature parameter 'pins this run's skill manifest') are mentioned in descriptions but not formally documented. Overall: functional definitions with room for LLM-optimized descriptions and structured error guidance.
Provision .mjloop/ in the project, detect verify commands, and register mjloop in CLAUDE.md. Idempotent.
Record which agents this cycle runs and why each omission is safe. Rejected if any agent the track marks required is missing, or if an optional agent is omitted without a stated reason. With closing=true it records the run closing pass instead, drawn from the closing set mjloop_cycle_advance reported on the pass.
Validate an agent result against the contract, persist it under the cycle, and fold findings into state.
Open a new run on a track. Resets cycle, findings, and history.
Compact summary of the current run: track, cycle, cap, stage, findings, halt reason.
Output schemas entirely undocumented. Tools return ToolResult with generic 'text' content; LLMs cannot infer structure of returned data (e.g., what fields does stateSummary() return? What is the shape of a roster response?). Breaks tool chaining and forces LLMs to parse unstructured text.
Parameter descriptions are generic and repeated verbatim ('Project root. Defaults to CLAUDE_PROJECT_DIR or cwd.') across all 5 tools. Does not explain WHEN to use each tool, WHAT it modifies, or dependencies between parameters (e.g., mjloop_roster_set's 'closing' parameter changes the meaning of 'cycle'). LLMs cannot distinguish tools or understand parameter relationships.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
No tool annotations despite clear risk profiles. mjloop_init and mjloop_run_start are destructive (WRITE); mjloop_state_get is read-only. Annotations (destructiveHint, readOnlyHint, idempotentHint) are missing, preventing agents from reasoning about retry safety and side effects.
Error handling is minimal. guard() catches exceptions and returns isError=true with message text, but does not categorize errors (retryable vs. user-fixable vs. fatal) or guide recovery. E.g., if mjloop_run_start fails because track is not found, the error message should suggest available tracks.
Parameter constraints not formalized. mjloop_run_start's 'supervision' enum is declared, but other parameters (track, goal, plan, story, feature) lack format/pattern constraints. No min/max for numeric parameters (e.g., mjloop_roster_set's 'cycle' is a number with no bounds). LLMs cannot validate inputs before calling.