Loading ToolBench
A lightweight MCP server for project-local bug-fix analysis and verified fix memory.
Moth provides two tools with complete input and output schemas via Zod, good descriptions, and proper registration. However, several definition-quality gaps limit the score: parameter descriptions lack depth and validation context, no enum constraints are present, error handling is generic without recovery guidance, and output schemas are not fully documented in descriptions. The tools address a narrow, specialized domain (error analysis + fix memory), which limits composition opportunities. Tool names are clear and action-oriented (analyze_error, remember_fix_result), but descriptions could be more specific about prerequisites and LLM-facing context.
Analyze provided error output and return a deterministic project-local fix brief.
Record verified project-local fix memory only after a fix/change was actually attempted, the verification command was actually run, and the result is clearly passed or failed.
Parameter descriptions lack validation context and format guidance. Example: 'error_output' is described as 'The error output to analyze' without specifying expected format, max length, or encoding. LLMs cannot infer whether to pass raw stderr, JSON, structured logs, or plaintext.
No enum constraints on 'verification_result' parameter in remember_fix_result, despite schema declaring enum=['passed', 'failed']. However, this enum exists in the Zod schema (rememberFixResultInputSchema) but may not be visible to LLM as a constrained set in all MCP client implementations. Parameter description should explicitly state the two allowed values.
Output schema documentation incomplete. Both tools return structuredContent but descriptions do not specify what fields the output object contains. LLMs cannot plan downstream operations without knowing the response structure. For example, analyze_error's output likely contains 'fix_brief' or 'recommendations', these are not documented in the tool description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2025-06-18+ | v2 |
Error handling does not guide recovery. The tools handle errors but do not return actionable messages. For example, if 'package_context' is malformed JSON, the error response should be 'Invalid package_context: expected JSON object with name, version, and dependencies fields', not a generic validation failure.
Parameter 'package_context' is described as 'Package metadata context (optional)' without specifying what fields it should contain (e.g., name, version, dependencies, scripts). LLMs cannot construct valid input without knowing the expected object shape.
Parameter 'relevant_files' is an array but the description is vague: 'Array of relevant files with path, language, excerpt, content, and metadata (optional)'. Should explicitly state: 'Array of objects, each with path (string), language (string), excerpt (string), and content (string). Maximum 50 files per call to avoid context explosion.'
No maximum length or content limits specified for 'error_output' parameter. A malicious or buggy LLM could pass gigabytes of error logs, causing memory exhaustion or timeouts. Should declare: 'error_output: string, max 10,000 characters'.
remember_fix_result lacks dependency hints. The description should note: 'Call analyze_error first to obtain an analysis_id and fingerprint. Do not call this tool until a fix was actually attempted and verified.' Current description assumes the LLM already knows this prerequisite.