Skip to main content
Glama
deenesjakoruzh
stfade

Moth

by stfade
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Moth — это легковесный MCP-сервер для анализа исправлений ошибок локально в проекте и хранения проверенных решений.

Что делает Moth

Moth получает вывод ошибок через MCP, скрывает потенциальные секретные данные, нормализует сбой, определяет вероятный стек, проверяет локальную память исправлений проекта и возвращает структурированную сводку по исправлению.

Moth не редактирует код, не выполняет команды оболочки, не сканирует репозитории, не требует бэкенда и не ведет глобальную базу данных ошибок.

Related MCP server: looplens-mcp

Почему Moth?

Контекст исправления ошибок часто локален для проекта: команда, которая завершилась сбоем, используемый фреймворк, близлежащие конфигурации, а также исправления, которые уже сработали или не сработали в этом репозитории.

Moth делает этот рабочий процесс компактным и явным. Он анализирует предоставленный контекст ошибки, предлагает лучшее первое исправление и записывает только проверенные результаты исправлений в локальную память проекта.

Быстрый старт

Требуется Node.js 18+.

Запуск напрямую:

npx -y @stfade/moth moth-mcp

Или глобальная установка:

npm install -g @stfade/moth
moth-mcp

Общая конфигурация MCP

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

Пример использования

При использовании Moth с поддерживаемым AI-агентом вы можете добавить простую подсказку вместе с ошибкой:

"Use Moth to analyze this error before fixing it."

Поддерживаемые клиенты

Клиент

Статус

Настройка

Codex

Готов к локальному плагину

Настройка

Claude Code

Готов к локальному плагину

Настройка

Cursor

Каркас плагина

Настройка

Gemini CLI

Каркас расширения

Настройка

Gemini Antigravity

Готов к конфигурации MCP

Настройка

OpenCode

Готов к конфигурации MCP

Настройка

Generic MCP

Готов к конфигурации

Настройка

«Готов к локальному плагину» означает, что обертка интеграции включена и может быть протестирована локально. Отправка в маркетплейс и одобрение пока не включены.

Инструменты

Moth предоставляет ровно два MCP-инструмента.

analyze_error

Анализирует предоставленный вывод ошибки перед попыткой исправления.

Поля ввода:

  • error_output

  • command?

  • cwd?

  • package_context?

  • relevant_files?

  • environment?

Поля вывода:

  • analysis_id

  • fingerprint

  • stack

  • likely_cause

  • best_first_fix

  • verification

  • prior_project_fixes

  • avoid

  • confidence

remember_fix_result

Записывает проверенную память исправлений локально в проекте.

Поля ввода:

  • analysis_id

  • fingerprint

  • stack

  • fix_attempted

  • verification_command

  • verification_result: "passed" | "failed"

  • notes?

Публичный ввод worked отклоняется. worked выводится из verification_result.

Жизненный цикл проверенной памяти

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

Вызывайте remember_fix_result только тогда, когда:

  1. исправление/изменение было действительно предпринято

  2. команда проверки действительно была выполнена

  3. результат четко «пройден» (passed) или «не пройден» (failed)

Не вызывайте его для предложений, пропущенных изменений, отсутствия проверки, неоднозначных результатов или догадок.

Локальная память

Проверенная память исправлений локально в проекте хранится по адресу:

.moth/fix-memory.jsonl

Moth хранит небольшой реестр анализа вне проекта, чтобы remember_fix_result мог сопоставить analysis_id с правильным путем к проекту после перезапуска MCP-сервера.

Навыки

Moth включает краткие навыки для совместимых агентов:

  • moth-debug-first-fix

  • moth-source-backed-research

  • moth-verify-fix

Сам MCP-сервер не выполняет поиск в реальном времени в интернете. Совместимые агенты могут использовать свои собственные инструменты поиска, руководствуясь навыками Moth, когда требуются внешние источники.

Безопасность

  • только чтение по умолчанию

  • никаких правок исходного кода

  • никакого выполнения команд оболочки

  • никакого сканирования всего репозитория

  • никакого фонового наблюдения

  • не требуется внешний сервис

  • скрывает потенциальные секретные данные перед анализом, ответами и записью в память

Разработка

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

Лицензия

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