stfade/moth

Moth is a lightweight MCP server for project-local bug-fix analysis and verified fix memory.
What Moth Does
Moth receives error output through MCP, redacts likely secrets, normalizes the failure, detects the likely stack, checks project-local fix memory, and returns a structured fix brief.
Moth does not edit code, run shell commands, crawl repositories, require a backend, or maintain a global bug database.
Why Moth?
Bug-fix context is often local to a project: the command that failed, the framework in use, nearby configuration, and fixes that have already worked or failed in that repo.
Moth keeps that workflow small and explicit. It analyzes provided error context, suggests a best first fix, and records only verified fix outcomes in project-local memory.
Quick Start
Requires Node.js 18+.
Run directly:
Or install globally:
Generic MCP config
Usage Example
When using Moth with a supported AI agent, you can include a simple prompt like this along with your error:
> "Use Moth to analyze this error before fixing it."
Supported Clients
| Client | Status | Setup |
| --- | --- | --- |
| Codex | Local plugin-ready | Setup |
| Claude Code | Local plugin-ready | Setup |
| Cursor | Plugin scaffold | Setup |
| Gemini CLI | Extension scaffold | Setup |
| Gemini Antigravity | MCP config-ready | Setup |
| OpenCode | MCP config-ready | Setup |
| Generic MCP | Config-ready | Setup |
“Local plugin-ready” means the integration wrapper is included and can be tested locally. Marketplace submission and approval are not included yet.
Tools
Moth exposes exactly two MCP tools.
analyze_error
Analyzes provided error output before a fix is attempted.
Input fields:
- error_output
- command?
- cwd?
- package_context?
- relevant_files?
- environment?
Output fields:
- analysis_id
- fingerprint
- stack
- likely_cause
- best_first_fix
- verification
- prior_project_fixes
- avoid
- confidence
remember_fix_result
Records verified project-local fix memory.
Input fields:
- analysis_id
- fingerprint
- stack
- fix_attempted
- verification_command
- verification_result: "passed" | "failed"
- notes?
The public worked input is rejected. worked is derived from verification_result.
Verified Memory Lifecycle
Call remember_fix_result only when:
1. a fix/change was actually attempted
2. the verification command actually ran
3. the result is clearly passed or failed
Do not call it for suggestions, skipped changes, missing verification, ambiguous results, or guesses.
Local Memory
Verified project-local fix memory is stored at: