Skip to main content
Glama
deenesjakoruzh
stfade

Moth

by stfade
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

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.

Related MCP server: looplens-mcp

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:

npx -y @stfade/moth moth-mcp

Or install globally:

npm install -g @stfade/moth
moth-mcp

Generic MCP config

{
  "mcpServers": {
    "moth": {
      "command": "npx",
      "args": ["-y", "@stfade/moth", "moth-mcp"]
    }
  }
}

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

analyze_error
→ apply/attempt fix
→ run verification command
→ remember_fix_result

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:

.moth/fix-memory.jsonl

Moth keeps a small Moth-owned analysis registry outside the project so remember_fix_result can map analysis_id back to the correct project path after an MCP server restart.

Skills

Moth includes concise skills for compatible agents:

  • moth-debug-first-fix

  • moth-source-backed-research

  • moth-verify-fix

The MCP server itself does not perform live web research. Compatible agents may use their own search tools, guided by Moth skills, when external sources are needed.

Safety

  • read-only by default

  • no source edits

  • no shell execution

  • no repo-wide scan

  • no background watcher

  • no external service required

  • redacts likely secrets before analysis, responses, and memory writes

Development

pnpm install
pnpm test
pnpm build
pnpm dev
npm pack --dry-run

License

MIT

Available Tools

2 tools
analyze_errorAnalyze ErrorC

Analyze provided error output and return a deterministic project-local fix brief.

ParametersJSON Schema
NameRequiredDescriptionDefault
error_outputYes
commandNo
cwdNo
package_contextNo
relevant_filesNo
environmentNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
analysis_idYes
fingerprintYes
stackYes
likely_causeYes
best_first_fixYes
verificationYes
prior_project_fixesYes
avoidYes
confidenceYes

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the output is 'deterministic' and 'project-local'. It does not disclose if the tool modifies state (e.g., reads files, changes anything), required permissions, or potential side effects, leaving agents to infer behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core purpose. However, it sacrifices critical parameter and usage details, which is a minor structural flaw given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having a rich input schema and output schema, the description omits explanation of parameter roles, return format, and usage context. For a complex analysis tool, this is incomplete, though the output schema may partially mitigate return value clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 6 parameters with 0% description coverage, yet the description adds no parameter information beyond mentioning 'error output' in the purpose. The other parameters (command, cwd, relevant_files, etc.) remain unexplained, forcing agents to guess their semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes error output and returns a deterministic project-local fix brief. It uses a specific verb ('analyze') and resource ('error output'), and the mention of 'fix brief' distinguishes it from the sibling tool 'remember_fix_result' which likely stores results.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus the sibling 'remember_fix_result' or other alternatives. The description implicitly suggests using it when an error occurs, but does not specify prerequisites or exclude scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remember_fix_resultRemember Fix ResultA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
analysis_idYes
fingerprintYes
stackYes
fix_attemptedYes
verification_commandYes
verification_resultYes
notesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
recordedYes
memory_pathYes
timestampYes

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool records memory only under specified conditions. However, it lacks details about side effects, authorization needs, or what happens if conditions are unmet. No annotations exist to supplement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the verb and resource, and includes necessary conditional clauses. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 required parameters and no annotations, the description is insufficient. It does not explain what 'fix memory' is, how to obtain analysis_id/fingerprint/stack, or what the output schema contains. An agent would struggle to use this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 7 parameters with 0% description coverage. The description does not explain any parameters, forcing agents to infer meaning from names alone. This is a significant gap given the tool's complexity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to record a verified fix result after a fix attempt and verification. It specifies the exact conditions (fix attempted, verification run, result passed/failed) and distinguishes from analyze_error.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use: only after a fix is attempted and verification run with a clear result. It does not explicitly state when not to use or mention alternatives, but the conditions are well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.1.0
    • First observedanalyze_error
    • First observedremember_fix_result
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: analyze_error generates a fix brief from error output, while remember_fix_result records the outcome of a fix attempt. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern in snake_case: analyze_error and remember_fix_result. The naming is clear and predictable.

Tool Count3/5

With only 2 tools, the server feels under-scoped for a typical error analysis workflow. While it may be intentionally minimal, a more comprehensive set would include tools for retrieving fix history or clearing memory.

Completeness3/5

The tool set lacks retrieval capabilities (e.g., listing or searching past fix results) and memory management (e.g., clearing or updating records). These are notable gaps that could hinder agent workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • looplens-mcp

    musaceylan
    A
    license
    B
    quality
    D
    maintenance
    An MCP server for detecting retry loops and analyzing iteration patterns in agentic coding workflows, providing structured debugging intelligence to improve repair attempts.
    16
    4
    MIT

  • Unravel MCP

    EruditeCoder108
    A
    license
    Not graded
    quality
    C
    maintenance
    A deterministic AST evidence engine that forces AI agents to debug using verified execution facts instead of pattern-matching symptoms, enabling hallucination-free debugging for MCP-compatible agents.
    11
    Business Source 1.1

  • elim-mcp

    DevAsadYasin
    A
    license
    Not graded
    quality
    B
    maintenance
    An MCP server that gives coding agents a persistent, chained memory of debugging investigations, tracking what's been tried, ruled out, and solved across sessions and scopes.
    20
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stfade/moth'

If you have feedback or need assistance with the MCP directory API, please join our Discord server