Skip to main content
Glama
deenesjakoruzh
stfade

Moth

by stfade
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Moth ist ein leichtgewichtiger MCP-Server für projektlokale Fehlerbehebungsanalysen und verifizierten Korrekturspeicher.

Was Moth tut

Moth empfängt Fehlerausgaben über MCP, schwärzt potenzielle Geheimnisse, normalisiert den Fehler, erkennt den wahrscheinlichen Stack, prüft den projektlokalen Korrekturspeicher und gibt eine strukturierte Zusammenfassung der Korrektur zurück.

Moth bearbeitet keinen Code, führt keine Shell-Befehle aus, durchsucht keine Repositories, benötigt kein Backend und verwaltet keine globale Fehlerdatenbank.

Related MCP server: looplens-mcp

Warum Moth?

Der Kontext für Fehlerbehebungen ist oft projektspezifisch: der Befehl, der fehlgeschlagen ist, das verwendete Framework, die Konfiguration in der Nähe sowie Korrekturen, die in diesem Repository bereits funktioniert haben oder fehlgeschlagen sind.

Moth hält diesen Workflow klein und explizit. Es analysiert den bereitgestellten Fehlerkontext, schlägt eine optimale erste Korrektur vor und speichert nur verifizierte Korrekturergebnisse im projektlokalen Speicher.

Schnellstart

Erfordert Node.js 18+.

Direkt ausführen:

npx -y @stfade/moth moth-mcp

Oder global installieren:

npm install -g @stfade/moth
moth-mcp

Generische MCP-Konfiguration

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

Anwendungsbeispiel

Wenn Sie Moth mit einem unterstützten KI-Agenten verwenden, können Sie zusammen mit Ihrem Fehler eine einfache Aufforderung wie diese einfügen:

"Verwende Moth, um diesen Fehler zu analysieren, bevor du ihn behebst."

Unterstützte Clients

Client

Status

Einrichtung

Codex

Lokales Plugin bereit

Einrichtung

Claude Code

Lokales Plugin bereit

Einrichtung

Cursor

Plugin-Gerüst

Einrichtung

Gemini CLI

Erweiterungs-Gerüst

Einrichtung

Gemini Antigravity

MCP-Konfiguration bereit

Einrichtung

OpenCode

MCP-Konfiguration bereit

Einrichtung

Generic MCP

Konfiguration bereit

Einrichtung

„Lokales Plugin bereit“ bedeutet, dass der Integrations-Wrapper enthalten ist und lokal getestet werden kann. Marktplatz-Einreichung und -Freigabe sind noch nicht enthalten.

Tools

Moth stellt genau zwei MCP-Tools bereit.

analyze_error

Analysiert die bereitgestellte Fehlerausgabe, bevor eine Korrektur versucht wird.

Eingabefelder:

  • error_output

  • command?

  • cwd?

  • package_context?

  • relevant_files?

  • environment?

Ausgabefelder:

  • analysis_id

  • fingerprint

  • stack

  • likely_cause

  • best_first_fix

  • verification

  • prior_project_fixes

  • avoid

  • confidence

remember_fix_result

Speichert verifizierte projektlokale Korrekturergebnisse.

Eingabefelder:

  • analysis_id

  • fingerprint

  • stack

  • fix_attempted

  • verification_command

  • verification_result: "passed" | "failed"

  • notes?

Die öffentliche Eingabe worked wird abgelehnt. worked wird aus verification_result abgeleitet.

Lebenszyklus des verifizierten Speichers

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

Rufen Sie remember_fix_result nur auf, wenn:

  1. tatsächlich eine Korrektur/Änderung versucht wurde

  2. der Verifizierungsbefehl tatsächlich ausgeführt wurde

  3. das Ergebnis eindeutig passed oder failed ist

Rufen Sie es nicht für Vorschläge, übersprungene Änderungen, fehlende Verifizierung, mehrdeutige Ergebnisse oder Vermutungen auf.

Lokaler Speicher

Der verifizierte projektlokale Korrekturspeicher wird hier gespeichert:

.moth/fix-memory.jsonl

Moth unterhält ein kleines, Moth-eigenes Analyseregister außerhalb des Projekts, damit remember_fix_result nach einem Neustart des MCP-Servers die analysis_id wieder dem korrekten Projektpfad zuordnen kann.

Skills

Moth enthält prägnante Skills für kompatible Agenten:

  • moth-debug-first-fix

  • moth-source-backed-research

  • moth-verify-fix

Der MCP-Server selbst führt keine Live-Webrecherche durch. Kompatible Agenten können ihre eigenen Suchwerkzeuge verwenden, geleitet durch Moth-Skills, wenn externe Quellen benötigt werden.

Sicherheit

  • standardmäßig schreibgeschützt

  • keine Quellcode-Änderungen

  • keine Shell-Ausführung

  • kein Scan des gesamten Repositorys

  • kein Hintergrund-Watcher

  • kein externer Dienst erforderlich

  • schwärzt potenzielle Geheimnisse vor der Analyse, den Antworten und dem Schreiben in den Speicher

Entwicklung

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

Lizenz

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.

  1. 2 tool updatesv0.1.0
    • First observedanalyze_error
    • First observedremember_fix_result
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored across 2 tools

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
ResponsivenessNo issues

Resources

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
    D
    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.
    8 npm
    Business Source 1.1

  • elim-mcp

    DevAsadYasin
    A
    license
    Not graded
    quality
    D
    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.
    28 npm
    MIT

Appeared in Searches