Skip to main content
Glama
deenesjakoruzh
stfade

Moth

by stfade
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Moth es un servidor MCP ligero para el análisis de corrección de errores local al proyecto y la memoria de correcciones verificadas.

Qué hace Moth

Moth recibe la salida de errores a través de MCP, redacta posibles secretos, normaliza el fallo, detecta la pila probable, comprueba la memoria de correcciones local del proyecto y devuelve un resumen de corrección estructurado.

Moth no edita código, no ejecuta comandos de shell, no rastrea repositorios, no requiere un backend ni mantiene una base de datos global de errores.

Related MCP server: looplens-mcp

¿Por qué Moth?

El contexto de corrección de errores suele ser local a un proyecto: el comando que falló, el framework en uso, la configuración cercana y las correcciones que ya han funcionado o fallado en ese repositorio.

Moth mantiene ese flujo de trabajo pequeño y explícito. Analiza el contexto de error proporcionado, sugiere una mejor primera corrección y registra solo los resultados de corrección verificados en la memoria local del proyecto.

Inicio rápido

Requiere Node.js 18+.

Ejecutar directamente:

npx -y @stfade/moth moth-mcp

O instalar globalmente:

npm install -g @stfade/moth
moth-mcp

Configuración genérica de MCP

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

Ejemplo de uso

Al usar Moth con un agente de IA compatible, puedes incluir un prompt simple como este junto con tu error:

"Usa Moth para analizar este error antes de corregirlo."

Clientes compatibles

Cliente

Estado

Configuración

Codex

Listo para plugin local

Configuración

Claude Code

Listo para plugin local

Configuración

Cursor

Estructura de plugin

Configuración

Gemini CLI

Estructura de extensión

Configuración

Gemini Antigravity

Listo para configuración MCP

Configuración

OpenCode

Listo para configuración MCP

Configuración

Generic MCP

Listo para configuración

Configuración

“Listo para plugin local” significa que el envoltorio de integración está incluido y puede probarse localmente. La presentación y aprobación en el Marketplace aún no están incluidas.

Herramientas

Moth expone exactamente dos herramientas MCP.

analyze_error

Analiza la salida de error proporcionada antes de intentar una corrección.

Campos de entrada:

  • error_output

  • command?

  • cwd?

  • package_context?

  • relevant_files?

  • environment?

Campos de salida:

  • analysis_id

  • fingerprint

  • stack

  • likely_cause

  • best_first_fix

  • verification

  • prior_project_fixes

  • avoid

  • confidence

remember_fix_result

Registra la memoria de corrección verificada local al proyecto.

Campos de entrada:

  • analysis_id

  • fingerprint

  • stack

  • fix_attempted

  • verification_command

  • verification_result: "passed" | "failed"

  • notes?

La entrada pública worked es rechazada. worked se deriva de verification_result.

Ciclo de vida de la memoria verificada

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

Llama a remember_fix_result solo cuando:

  1. se intentó realmente una corrección/cambio

  2. el comando de verificación se ejecutó realmente

  3. el resultado es claramente passed o failed

No lo llames para sugerencias, cambios omitidos, falta de verificación, resultados ambiguos o suposiciones.

Memoria local

La memoria de corrección verificada local al proyecto se almacena en:

.moth/fix-memory.jsonl

Moth mantiene un pequeño registro de análisis propiedad de Moth fuera del proyecto para que remember_fix_result pueda asignar analysis_id de nuevo a la ruta correcta del proyecto después de un reinicio del servidor MCP.

Habilidades

Moth incluye habilidades concisas para agentes compatibles:

  • moth-debug-first-fix

  • moth-source-backed-research

  • moth-verify-fix

El servidor MCP en sí no realiza investigación web en vivo. Los agentes compatibles pueden usar sus propias herramientas de búsqueda, guiados por las habilidades de Moth, cuando se necesiten fuentes externas.

Seguridad

  • solo lectura por defecto

  • sin ediciones de código fuente

  • sin ejecución de shell

  • sin escaneo de todo el repositorio

  • sin observador en segundo plano

  • no requiere servicio externo

  • redacta posibles secretos antes del análisis, las respuestas y las escrituras en memoria

Desarrollo

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

Licencia

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