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

로컬 플러그인 준비 완료

설정

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는 MCP 서버 재시작 후 remember_fix_result가 올바른 프로젝트 경로를 매핑할 수 있도록 프로젝트 외부에 작은 Moth 전용 분석 레지스트리를 유지합니다.

스킬

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.

  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