Skip to main content
Glama
deenesjakoruzh
stfade

Moth

by stfade
OverviewSchemaSourceRelated ServersDiscussionsAdmin
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

ローカルプラグイン対応

Setup

Claude Code

ローカルプラグイン対応

Setup

Cursor

プラグイン構成

Setup

Gemini CLI

拡張機能構成

Setup

Gemini Antigravity

MCP設定対応

Setup

OpenCode

MCP設定対応

Setup

Generic MCP

設定対応

Setup

「ローカルプラグイン対応」とは、統合ラッパーが含まれており、ローカルでテスト可能であることを意味します。マーケットプレイスへの提出と承認はまだ含まれていません。

ツール

Mothは正確に2つの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は、MCPサーバーの再起動後に remember_fix_result が analysis_id を正しいプロジェクトパスにマッピングできるように、プロジェクト外にMoth独自の小さな分析レジストリを保持します。

スキル

Mothには、互換性のあるエージェント向けの簡潔なスキルが含まれています:

  • moth-debug-first-fix

  • moth-source-backed-research

  • moth-verify-fix

Mothサーバー自体はライブWebリサーチを実行しません。互換性のあるエージェントは、外部ソースが必要な場合、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.

  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