SkillTide Submit
Official description7 sourcesMCP servers8d ago
FailEcho/failecho

FailEcho/failecho

Cross-agent failure intelligence: befo
View on GitHub ↗Direct link · no redirect page
Config template (adjust for your client)
claude mcp add failecho -- npx -y failecho
A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
2 ★ · FailEcho/failecho · read from the GitHub search API · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 2 ★ · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository FailEcho/failecho;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
Third-party quality signals

**Failure intelligence for AI agents and autonomous software.**

以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →

Before you retry, check the echo.
Website ·
Connect an agent ·
API reference ·
Live network ·
llms.txt
FailEcho is a cross-agent failure intelligence network. When a tool or model
call fails, it tells your agent what fixed that exact failure for other agents
-- or that nothing has, so it stops retrying.
Agents share the shape of their failures and what fixed them (metadata only,
never prompts or data); the next agent to hit the same failure gets the
answer. Open source, no account.
Every line is real output: live queries to the lab network, one twin pair replayed from the lab ledger (24 Sep), the wrapper's actual payload, and the lab scoreboard with p-values. Our own agents; independent reporters so far: 0.
What we have measured, and what we have not
Our own agents run in twins in a lab: same task, same model, one asks FailEcho
before it retries and acts on the answer, one does not. Measured 22-24
September 2026. **Independent users so far: 0.** Every number, its sample and
its significance test: docs/claims.md; live:
the lab scoreboard.
| Measured (p in front of each MCP server | inside the failing tool's error |
| Your own code | failecho-autoreport with FAILECHO_ADVISE=1 | on the exception you already handle |
| Nothing can be installed | the bare MCP endpoint below | only if the model remembers to ask |
All four deliver the advice, and all four are tested end to end. The gains
the lab has measured come from agents that **act** on it -- switch model when
told switch_model, stop when told skip (three lines with the
wrapper); none of the four integrations has a
lab comparison of its own with a result to quote yet.
**The bare MCP endpoint** -- the smallest option and the least effective
Most MCP clients take this config block:
In Claude Code that file is .mcp.json; Cursor uses .cursor/mcp.json and
drops the type; VS Code uses .vscode/mcp.json and calls the top-level key
servers. The endpoint never changes. The setup
page has the table.
On Claude Code the CLI writes that same file for you:
Python, if you want failures *and* successes reported automatically:
No account. No API key. Free during the public MVP.
Full integration guide: Connect an agent.
What it does
See whether other AI agents are hitting the same tool failure right now — and
which recovery actions actually worked. FailEcho exposes a Model Context
Protocol (MCP) endpoint that agents can query after a tool failure, plus a REST
API.
| Tool | When the agent calls it |
|---|---|
| check_tool_failure | a tool failed — **before** retrying |
| report_tool_failure | contribute the failure |
| report_tool_success | contribute a success (the denominator) |
| report_recovery_outcome | say whether the fix worked |
FailEcho normalizes error text deterministically (no model) into a fingerprint,
accumulates recovery outcomes against it, and returns a recommendation only
when independent reporters agree. Thin evidence returns INSUFFICIENT_DATA
rather than a guess. Confidence is a Wilson score lower bound you can recompute
from the counts returned beside it.
It stores failure **metadata** only. There is no field for prompts, tool
arguments, tool results, request or response bodies, headers or cookies, so
none of it can be stored. One field is free text, the error message: optional,
off by default in the hook and the wrapper, and when sent it is normalized --
identifiers replaced, credential-shaped strings redacted -- and the raw text
discarded. That normalization is a second line of defence, not a guarantee;
the honest claim is *metadata only, error text off by default, normalized when
on*.
**Live:** · /docs ·
/openapi.json ·
/llms.txt
This is **not** an observability platform, an error database, an uptime monitor
or an LLM debugger. The unit of the system is:
Vocabulary
| Term | Meaning |
|---|---|
| **FailEcho Network** | the whole system |
| **Failure Echo** | a normalized observed failure, shared by fingerprint |
| **Recovery Echo** | evidence that a recovery action worked |
| **Incident** | a sudden abnormal failure increase |
| **Reporter** | an agent or runtime sending telemetry |
| **Fingerprint** | the canonical normalized error identity |
The brand vocabulary is for humans. Wire formats are deliberately unbranded:
endpoint paths, MCP tool names and field names (fingerprint,
recommendation, recovery_actions) stay exactly as they are, because machine
clarity outranks naming purity.
---
See the network effect locally
Two terminals, about a minute.
Source
awesome · https://github.com/FailEcho/failecho
Browse by field
MCP servers
Traction
2 ★
added
yesterday

More in MCP servers

All 5,525 in MCP servers →

Filed under

Every tag opens the full list for that filter. Counts are the live catalogue figures.

Browse all fields →

← Back to index