failecho

Name: failecho
Author: FailEcho

by com.failecho

Overview Discussions Admin

Server Details

Check what other agents hit the same tool failure — and what recovery worked. Ask before retrying.

Ownership verified

Status: Healthy
Uptime: 99.9% over 23 days
Last Tested: 2026-10-02 14:35
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: FailEcho/failecho
GitHub Stars: 2
Server Listing: FailEcho

TDQS

A4.4/5.0

Scored 2026-09-24 20:00 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: check_tool_failure queries shared failure intelligence, report_tool_failure submits a failure, report_tool_success submits a success, and report_recovery_outcome records the result of a recovery attempt. The descriptions explicitly separate when each should be called, so an agent should not confuse them.

Naming Consistency5/5

All tool names follow the same verb_noun snake_case pattern: check_tool_failure, report_tool_failure, report_tool_success, and report_recovery_outcome. The report_* prefix creates a clear family while check_tool_failure stands apart as the read operation, making the interface predictable.

Tool Count5/5

Four tools is well-scoped for a focused failure-intelligence service. Each tool covers a distinct necessary operation: querying, failure reporting, success reporting, and recovery outcome reporting, with no redundant or filler tools.

Completeness5/5

The tool surface forms a complete cycle for the domain: agents can query known failure intelligence, contribute new failures, report successes to keep statistics meaningful, and log recovery outcomes to improve future recommendations. No obvious dead ends or missing operations are apparent.

Available Tools

4 tools

check_tool_failureCheck what the network knows about a tool failureA

Read-onlyIdempotent

Inspect

Use FailEcho when another tool fails, before retrying blindly. Call this BEFORE retrying a failed tool, API or MCP call. Returns what other agents saw for this exact failure -- status (HEALTHY/DEGRADED/MAJOR/INSUFFICIENT_DATA), counts, the recovery actions that worked with success rates, and one recommendation (or skip when nothing tried recently has worked; null when evidence is thin -- a real answer). Works on your own history before anyone else joins. Free, anonymous, stores nothing, never rate limited.

ParametersJSON Schema

Name	Required	Description
`service`	Yes	The MCP server's own name (serverInfo.name) or the API host, e.g. 'api.github.com'. Not your client's local alias.
`verbose`	No	Full record (timestamps, rates, effective counts, every action). Default: the compact answer.
`version`	No	Service/tool version, if known.
`operation`	Yes	The tool or endpoint as the server names it, e.g. 'create_issue', not 'mcp__github__create_issue'.
`error_code`	No	Code, e.g. '422', 'ECONNRESET'.
`error_type`	No	Failure class, e.g. 'validation_error', 'timeout', 'rate_limit', 'auth_error'.
`reporter_id`	No	Optional stable agent id; hashed, never stored raw. Lets from_other_agents be answered.
`schema_hash`	No	Short hash of the tool schema you used (separates 'API broke' from 'schema stale').
`error_message`	No	The error text only; normalized server-side, not stored by this call.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: it is anonymous, stores nothing, never rate limited, and works on personal history before others join. No contradiction with annotations.

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 dense and front-loaded, with purpose stated in the first sentence. The first two sentences are somewhat redundant ('Use FailEcho when another tool fails' and 'Call this BEFORE retrying a failed tool'), but all other content earns its place, especially the output semantics and guarantees.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a rich output schema, 100% parameter coverage, and robust annotations, the description fully covers what the agent needs: when to call, what it returns, edge cases (skip/null), and operational guarantees. Nothing important is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 with the schema carrying parameter meaning. The description adds context about how parameters together identify an 'exact failure' and explains output semantics, but it does not add per-parameter detail beyond the schema.

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 states a concrete action—query FailEcho about a tool failure—and clearly explains what it returns (status, counts, recovery actions, recommendation). It contrasts with the sibling report_* tools by being the check/query counterpart, so an agent can distinguish it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it ('when another tool fails'), the required ordering ('Call this BEFORE retrying'), and the scope (failed tool, API, or MCP call). It also clarifies the semantics of recommendation outputs ('skip' vs null) so the agent knows what to expect in different evidence conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

report_recovery_outcomeReport whether a recovery action workedAInspect

After acting on a failure -- retry, wait, refresh_schema, reconnect, use_fallback, reauthenticate -- report whether it worked. Every recommendation others get is built from these. Pass the fingerprint from check_tool_failure or report_tool_failure; one outcome per attempt.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	What you tried, e.g. 'refresh_schema' ([a-z0-9_.-]).
`successful`	Yes	True when the action resolved the failure.
`fingerprint`	Yes	From check_tool_failure or report_tool_failure (32 hex chars).
`reporter_id`	No	Optional stable agent id; hashed, never stored raw.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only show all hints false, so the description adds value by explaining that 'Every recommendation others get is built from these'—indicating the report feeds a recommendation system. It also adds the 'one outcome per attempt' constraint. It doesn't disclose side effects like rate limits, but the added context is meaningful.

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?

Two tightly written sentences: the first front-loads the trigger condition and action, the second explains the importance and the fingerprint requirement. No wasted words or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers when to use, what to report, and where to get the fingerprint, which is sufficient for a tool with 3 required parameters and a full output schema. The output schema already covers return values, so nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter already described including patterns (fingerprint hex) and maximum lengths. The description reinforces fingerprint provenance and adds the 'one outcome per attempt' rule, but this is usage guidance rather than new parameter meaning. Baseline of 3 is appropriate.

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 states the exact action and resource: 'report whether it worked' after acting on a failure, with a specific list of recovery actions (retry, wait, refresh_schema, etc.). It clearly distinguishes this tool from siblings by focusing on recovery outcomes rather than initial failure reporting.

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?

It explicitly says when to use: 'After acting on a failure... report whether it worked,' and instructs to pass the fingerprint from check_tool_failure or report_tool_failure, with one outcome per attempt. It does not explicitly name alternatives to avoid or state when-not, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

report_tool_failureReport a failed tool call to the networkAInspect

Report a failed tool/API/MCP call so others can recognise it; call after a failure, alongside check_tool_failure.

PRIVACY: this is a shared network. Send failure metadata only -- never prompts, tool arguments, tool results, request or response bodies, headers, cookies, API keys, tokens, emails or user content. Error text is normalized server-side and the raw string discarded. A stable reporter_id (hashed, never stored raw) makes you one reporter instead of anonymous noise. Writes are rate limited per client.

ParametersJSON Schema

Name	Required	Description
`service`	Yes	The MCP server's own name (serverInfo.name) or the API host, e.g. 'api.github.com'. Not your client's local alias.
`version`	No	Version of the service/tool.
`operation`	Yes	The tool or endpoint as the server names it, e.g. 'create_issue', not 'mcp__github__create_issue'.
`error_code`	No	Protocol/vendor code, e.g. '422'.
`error_type`	No	Short failure class, e.g. 'validation_error'.
`latency_ms`	No	Observed call latency in milliseconds.
`reporter_id`	No	Optional stable identifier for your agent. Salted and hashed on arrival; never stored raw.
`schema_hash`	No	Short hash of the tool schema used.
`error_message`	No	Error text. Normalized before storage; no secrets please.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The privacy paragraph adds substantial behavioral context beyond the sparse annotations: shared network, metadata-only policy, server-side normalization, hashed reporter_id, and per-client rate limiting. This is critical operational information that helps the agent use the tool safely and would not be derivable from the schema or annotations.

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?

Two tight paragraphs: the purpose is front-loaded in one sentence, and the privacy/behavior block is densely packed with essential exceptions. No filler, though the privacy section is long enough that it could be considered slightly heavy or combined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% parameter coverage, the description provides the missing operational context: when to call, privacy boundaries, rate limiting, and identity hashing. It does not explain the response shape, but the output schema covers that. Overall adequate for a side-effectful reporting tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces privacy constraints (e.g., no secrets in error_message) and the hashing behavior of reporter_id, but these are already present in the schema descriptions. It adds no new per-parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Report a failed tool/API/MCP call so others can recognise it') and gives clear context ('call after a failure'). It names a sibling (check_tool_failure) but does not explicitly contrast with report_tool_success or report_recovery_outcome, so it stops short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to call it ('after a failure') and suggests a companion call ('alongside check_tool_failure'). However, it provides no guidance on when NOT to use it versus the other sibling tools, leaving some routing decisions to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

report_tool_successReport a successful tool call to the networkAInspect

Report that a call SUCCEEDED. Failure rates are failures over all calls; a network that only hears failures cannot tell broken from busy. No error data -- service, operation, version, latency.

ParametersJSON Schema

Name	Required	Description
`service`	Yes	The MCP server's own name (serverInfo.name) or the API host, e.g. 'api.github.com'. Not your client's local alias.
`version`	No	Version of the service/tool.
`operation`	Yes	The tool or endpoint as the server names it, e.g. 'create_issue', not 'mcp__github__create_issue'.
`latency_ms`	No	Observed call latency in milliseconds.
`reporter_id`	No	Optional stable agent id; hashed, never stored raw.
`schema_hash`	No	Short hash of the tool schema used.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations indicate no readOnly or idempotent hints, so the description must convey the behavioral impact. It states what to report (latency, service, operation) and what not to report (error data), adding context about the network's aggregation, which is beyond the annotation schema.

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, tightly packed sentence followed by a short exclusion list. It front-loads the core purpose and adds critical context without unnecessary fluff. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema and high schema coverage, the description covers the necessary context for calling it. It explains the rationale for reporting successes and what to exclude (error data), but could have been more explicit about when to use it versus report_tool_failure. Minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds extra guidance on the 'service' (server's own name vs client alias) and 'operation' (server naming), which enriches the parameter meanings. This extra semantic guidance justifies a 4.

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 verb 'Report' and the resource 'a call SUCCEEDED', and explicitly contrasts with failure reporting. It distinguishes from siblings like report_tool_failure by defining the success event and what data to exclude.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly frames the network's failure-rate logic, saying a network that only hears failures cannot tell broken from busy, which guides when to call this tool to report successes. It does not name siblings directly but the context makes the usage clear.

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.

4 tool updatesSep 19, 2026
- Changedcheck_tool_failure24 fields changed
  - removedInput schema / properties / error_code / anyOf
```
Removed value: -[
-  {
-    "maxLength": 32,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / error_code / default
```
Removed value: -null
```
  - addedInput schema / properties / error_code / maxLength
```
Added value: +32
```
  - addedInput schema / properties / error_code / type
```
Added value: +"string"
```
  - removedInput schema / properties / error_message / anyOf
```
Removed value: -[
-  {
-    "maxLength": 2000,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / error_message / default
```
Removed value: -null
```
  - addedInput schema / properties / error_message / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / error_message / type
```
Added value: +"string"
```
  - removedInput schema / properties / error_type / anyOf
```
Removed value: -[
-  {
-    "maxLength": 64,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / error_type / default
```
Removed value: -null
```
  - addedInput schema / properties / error_type / maxLength
```
Added value: +64
```
  - addedInput schema / properties / error_type / type
```
Added value: +"string"
```
  - removedInput schema / properties / reporter_id / anyOf
```
Removed value: -[
-  {
-    "maxLength": 200,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / reporter_id / default
```
Removed value: -null
```
  - addedInput schema / properties / reporter_id / maxLength
```
Added value: +200
```
  - addedInput schema / properties / reporter_id / type
```
Added value: +"string"
```
  - removedInput schema / properties / schema_hash / anyOf
```
Removed value: -[
-  {
-    "maxLength": 64,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / schema_hash / default
```
Removed value: -null
```
  - addedInput schema / properties / schema_hash / maxLength
```
Added value: +64
```
  - addedInput schema / properties / schema_hash / type
```
Added value: +"string"
```
  - removedInput schema / properties / version / anyOf
```
Removed value: -[
-  {
-    "maxLength": 64,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / version / default
```
Removed value: -null
```
  - addedInput schema / properties / version / maxLength
```
Added value: +64
```
  - addedInput schema / properties / version / type
```
Added value: +"string"
```
- Changedreport_recovery_outcome4 fields changed
  - removedInput schema / properties / reporter_id / anyOf
```
Removed value: -[
-  {
-    "maxLength": 200,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / reporter_id / default
```
Removed value: -null
```
  - addedInput schema / properties / reporter_id / maxLength
```
Added value: +200
```
  - addedInput schema / properties / reporter_id / type
```
Added value: +"string"
```
- Changedreport_tool_failure28 fields changed
  - removedInput schema / properties / error_code / anyOf
```
Removed value: -[
-  {
-    "maxLength": 32,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / error_code / default
```
Removed value: -null
```
  - addedInput schema / properties / error_code / maxLength
```
Added value: +32
```
  - addedInput schema / properties / error_code / type
```
Added value: +"string"
```
  - removedInput schema / properties / error_message / anyOf
```
Removed value: -[
-  {
-    "maxLength": 2000,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / error_message / default
```
Removed value: -null
```
  - addedInput schema / properties / error_message / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / error_message / type
```
Added value: +"string"
```
  - removedInput schema / properties / error_type / anyOf
```
Removed value: -[
-  {
-    "maxLength": 64,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / error_type / default
```
Removed value: -null
```
  - addedInput schema / properties / error_type / maxLength
```
Added value: +64
```
  - addedInput schema / properties / error_type / type
```
Added value: +"string"
```
  - removedInput schema / properties / latency_ms / anyOf
```
Removed value: -[
-  {
-    "minimum": 0,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / latency_ms / default
```
Removed value: -null
```
  - addedInput schema / properties / latency_ms / minimum
```
Added value: +0
```
  - addedInput schema / properties / latency_ms / type
```
Added value: +"integer"
```
  - removedInput schema / properties / reporter_id / anyOf
```
Removed value: -[
-  {
-    "maxLength": 200,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / reporter_id / default
```
Removed value: -null
```
  - addedInput schema / properties / reporter_id / maxLength
```
Added value: +200
```
  - addedInput schema / properties / reporter_id / type
```
Added value: +"string"
```
  - removedInput schema / properties / schema_hash / anyOf
```
Removed value: -[
-  {
-    "maxLength": 64,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / schema_hash / default
```
Removed value: -null
```
  - addedInput schema / properties / schema_hash / maxLength
```
Added value: +64
```
  - addedInput schema / properties / schema_hash / type
```
Added value: +"string"
```
  - removedInput schema / properties / version / anyOf
```
Removed value: -[
-  {
-    "maxLength": 64,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / version / default
```
Removed value: -null
```
  - addedInput schema / properties / version / maxLength
```
Added value: +64
```
  - addedInput schema / properties / version / type
```
Added value: +"string"
```
- Changedreport_tool_success16 fields changed
  - removedInput schema / properties / latency_ms / anyOf
```
Removed value: -[
-  {
-    "minimum": 0,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / latency_ms / default
```
Removed value: -null
```
  - addedInput schema / properties / latency_ms / minimum
```
Added value: +0
```
  - addedInput schema / properties / latency_ms / type
```
Added value: +"integer"
```
  - removedInput schema / properties / reporter_id / anyOf
```
Removed value: -[
-  {
-    "maxLength": 200,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / reporter_id / default
```
Removed value: -null
```
  - addedInput schema / properties / reporter_id / maxLength
```
Added value: +200
```
  - addedInput schema / properties / reporter_id / type
```
Added value: +"string"
```
  - removedInput schema / properties / schema_hash / anyOf
```
Removed value: -[
-  {
-    "maxLength": 64,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / schema_hash / default
```
Removed value: -null
```
  - addedInput schema / properties / schema_hash / maxLength
```
Added value: +64
```
  - addedInput schema / properties / schema_hash / type
```
Added value: +"string"
```
  - removedInput schema / properties / version / anyOf
```
Removed value: -[
-  {
-    "maxLength": 64,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
  - removedInput schema / properties / version / default
```
Removed value: -null
```
  - addedInput schema / properties / version / maxLength
```
Added value: +64
```
  - addedInput schema / properties / version / type
```
Added value: +"string"
```

4 tool updatesSep 17, 2026

Changedcheck_tool_failure19 fields changed

changedInput schema / properties / error_code / description

Previous value: -"Protocol/vendor code, e.g. '422', 'ECONNRESET'."New value: +"Code, e.g. '422', 'ECONNRESET'."

removedInput schema / properties / error_code / title
```
Removed value: -"Error Code"
```

changedInput schema / properties / error_message / description

Previous value: -"The error text you received. Normalized server-side (identifiers replaced, credential-shaped substrings redacted) and never stored by this call. Do not include prompts, tool arguments, secrets or user content."New value: +"The error text only; normalized server-side, not stored by this call."

removedInput schema / properties / error_message / title
```
Removed value: -"Error Message"
```

changedInput schema / properties / error_type / description

Previous value: -"Short failure class, e.g. 'validation_error', 'timeout', 'rate_limit', 'auth_error'."New value: +"Failure class, e.g. 'validation_error', 'timeout', 'rate_limit', 'auth_error'."

removedInput schema / properties / error_type / title
```
Removed value: -"Error Type"
```

changedInput schema / properties / operation / description

Previous value: -"The tool or endpoint exactly as the server defines it, e.g. 'create_issue' -- without client prefixes such as 'mcp__github__'."New value: +"The tool or endpoint as the server names it, e.g. 'create_issue', not 'mcp__github__create_issue'."

removedInput schema / properties / operation / title
```
Removed value: -"Operation"
```

changedInput schema / properties / reporter_id / description

Previous value: -"Optional stable identifier for your agent. Salted and hashed on arrival and never stored by this call; it only lets FailEcho tell whether the evidence it just gave you came from a different reporter."New value: +"Optional stable agent id; hashed, never stored raw. Lets from_other_agents be answered."

removedInput schema / properties / reporter_id / title
```
Removed value: -"Reporter Id"
```

changedInput schema / properties / schema_hash / description

Previous value: -"Short hash of the tool schema you used. Lets FailEcho separate 'the API broke' from 'your tool schema is stale'."New value: +"Short hash of the tool schema you used (separates 'API broke' from 'schema stale')."

removedInput schema / properties / schema_hash / title
```
Removed value: -"Schema Hash"
```

changedInput schema / properties / service / description

Previous value: -"What was called, named the way other agents will name it: an MCP server's own name (the one it reports in serverInfo.name), or an HTTP API's host, e.g. 'api.github.com'. Not your client's local alias for it."New value: +"The MCP server's own name (serverInfo.name) or the API host, e.g. 'api.github.com'. Not your client's local alias."

removedInput schema / properties / service / title
```
Removed value: -"Service"
```

changedInput schema / properties / verbose / description

Previous value: -"Return the full record (timestamps, per-window rates, effective counts, every action). Default false: the compact answer an agent acts on, about a quarter of the tokens."New value: +"Full record (timestamps, rates, effective counts, every action). Default: the compact answer."

removedInput schema / properties / verbose / title
```
Removed value: -"Verbose"
```

changedInput schema / properties / version / description

Previous value: -"Version of the failing service/tool, if known."New value: +"Service/tool version, if known."

removedInput schema / properties / version / title
```
Removed value: -"Version"
```

removedInput schema / title

Removed value: -"check_tool_failureArguments"

Changedreport_recovery_outcome7 fields changed

changedInput schema / properties / action / description

Previous value: -"What you tried, e.g. 'refresh_schema'. Lowercase, [a-z0-9_.-], spaces become underscores."New value: +"What you tried, e.g. 'refresh_schema' ([a-z0-9_.-])."

removedInput schema / properties / action / title
```
Removed value: -"Action"
```

changedInput schema / properties / fingerprint / description

Previous value: -"Fingerprint from check_tool_failure or report_tool_failure (32 lowercase hex characters)."New value: +"From check_tool_failure or report_tool_failure (32 hex chars)."

removedInput schema / properties / fingerprint / title
```
Removed value: -"Fingerprint"
```
removedInput schema / properties / reporter_id / title
```
Removed value: -"Reporter Id"
```
removedInput schema / properties / successful / title
```
Removed value: -"Successful"
```

removedInput schema / title

Removed value: -"report_recovery_outcomeArguments"

Changedreport_tool_failure12 fields changed

removedInput schema / properties / error_code / title
```
Removed value: -"Error Code"
```
removedInput schema / properties / error_message / title
```
Removed value: -"Error Message"
```
removedInput schema / properties / error_type / title
```
Removed value: -"Error Type"
```
removedInput schema / properties / latency_ms / title
```
Removed value: -"Latency Ms"
```

changedInput schema / properties / operation / description

Previous value: -"The tool or endpoint exactly as the server defines it, e.g. 'create_issue' -- without client prefixes such as 'mcp__github__'."New value: +"The tool or endpoint as the server names it, e.g. 'create_issue', not 'mcp__github__create_issue'."

removedInput schema / properties / operation / title
```
Removed value: -"Operation"
```
removedInput schema / properties / reporter_id / title
```
Removed value: -"Reporter Id"
```
removedInput schema / properties / schema_hash / title
```
Removed value: -"Schema Hash"
```

changedInput schema / properties / service / description

Previous value: -"What was called, named the way other agents will name it: an MCP server's own name (the one it reports in serverInfo.name), or an HTTP API's host, e.g. 'api.github.com'. Not your client's local alias for it."New value: +"The MCP server's own name (serverInfo.name) or the API host, e.g. 'api.github.com'. Not your client's local alias."

removedInput schema / properties / service / title
```
Removed value: -"Service"
```
removedInput schema / properties / version / title
```
Removed value: -"Version"
```

removedInput schema / title

Removed value: -"report_tool_failureArguments"

Changedreport_tool_success9 fields changed

removedInput schema / properties / latency_ms / title
```
Removed value: -"Latency Ms"
```

changedInput schema / properties / operation / description

Previous value: -"The tool or endpoint exactly as the server defines it, e.g. 'create_issue' -- without client prefixes such as 'mcp__github__'."New value: +"The tool or endpoint as the server names it, e.g. 'create_issue', not 'mcp__github__create_issue'."

removedInput schema / properties / operation / title
```
Removed value: -"Operation"
```
removedInput schema / properties / reporter_id / title
```
Removed value: -"Reporter Id"
```
removedInput schema / properties / schema_hash / title
```
Removed value: -"Schema Hash"
```

changedInput schema / properties / service / description

Previous value: -"What was called, named the way other agents will name it: an MCP server's own name (the one it reports in serverInfo.name), or an HTTP API's host, e.g. 'api.github.com'. Not your client's local alias for it."New value: +"The MCP server's own name (serverInfo.name) or the API host, e.g. 'api.github.com'. Not your client's local alias."

removedInput schema / properties / service / title
```
Removed value: -"Service"
```
removedInput schema / properties / version / title
```
Removed value: -"Version"
```

removedInput schema / title

Removed value: -"report_tool_successArguments"

1 tool updateSep 17, 2026

Changedcheck_tool_failure1 field changed

addedInput schema / properties / verbose

Added value: +{
+  "default": false,
+  "description": "Return the full record (timestamps, per-window rates, effective counts, every action). Default false: the compact answer an agent acts on, about a quarter of the tokens.",
+  "title": "Verbose",
+  "type": "boolean"
+}

3 tool updatesSep 11, 2026

Changedcheck_tool_failure2 fields changed

changedInput schema / properties / operation / description

Previous value: -"Operation/tool name that failed, e.g. 'create_issue'."New value: +"The tool or endpoint exactly as the server defines it, e.g. 'create_issue' -- without client prefixes such as 'mcp__github__'."

changedInput schema / properties / service / description

Previous value: -"Tool/service identifier, e.g. 'github-mcp'."New value: +"What was called, named the way other agents will name it: an MCP server's own name (the one it reports in serverInfo.name), or an HTTP API's host, e.g. 'api.github.com'. Not your client's local alias for it."

Changedreport_tool_failure2 fields changed

changedInput schema / properties / operation / description

Previous value: -"Operation that failed."New value: +"The tool or endpoint exactly as the server defines it, e.g. 'create_issue' -- without client prefixes such as 'mcp__github__'."

changedInput schema / properties / service / description

Previous value: -"Tool/service identifier."New value: +"What was called, named the way other agents will name it: an MCP server's own name (the one it reports in serverInfo.name), or an HTTP API's host, e.g. 'api.github.com'. Not your client's local alias for it."

Changedreport_tool_success2 fields changed

changedInput schema / properties / operation / description

Previous value: -"Operation that succeeded."New value: +"The tool or endpoint exactly as the server defines it, e.g. 'create_issue' -- without client prefixes such as 'mcp__github__'."

changedInput schema / properties / service / description

Previous value: -"Tool/service identifier."New value: +"What was called, named the way other agents will name it: an MCP server's own name (the one it reports in serverInfo.name), or an HTTP API's host, e.g. 'api.github.com'. Not your client's local alias for it."

4 tool updatesSep 10, 2026
- First observedcheck_tool_failure
- First observedreport_recovery_outcome
- First observedreport_tool_failure
- First observedreport_tool_success

Publisher details

Operator: FailEcho · Publisher source
Operator website: https://failecho.com
Vendor relationship: First-party
Documentation: https://failecho.com/setup
Trust center: Not available
Restrictions: None. No account, no API key, no OAuth app, no paid plan, no admin approval, no regional limits. Reads are unauthenticated and never rate limited; writes are rate limited to 120 per minute per IP. MIT licensed and self-hostable if you would rather not use the shared endpoint.

Related MCP Connectors

MisakaNet A
org.misakanet
Never let your agent repeat a bug or linger on a known issue. Search 385+ failure lessons to skip known errors instantly.
Developer Tools Knowledge & Memory Search
72
Detextit by Shekkizh A
com.detextit.www
Find shared agent issues, sourced context and capabilities, or plan recovery from a constraint.
Search Documentation Access Developer Tools
51
deadends.dev
dev.deadends
Structured failure knowledge for AI agents — dead ends, workarounds, error chains
Knowledge & Memory Autonomous Agents Documentation Access
1
knowbase A
sh.knowbase
What other agents already tried against your build error, which attempt worked, and the dead ends
Knowledge & Memory Developer Tools
1

Related MCP Servers

unstuck-mcp
Coding Agents Autonomous Agents
SamuelH98
F
license
A
quality
C
maintenance
Prevents coding agents from repeatedly attempting the same failed fix by tracking attempts and blocking further fixes until the agent uses its own web search tool.
Updated 3 months ago (2026-07-12 21:03 UTC)
4
-
MisakaNet
Agent Orchestration Developer Tools Knowledge & Memory
Ikalus1988
A
license
A
quality
A
maintenance
Agent failure memory network. Search 235+ verified debugging lessons from real engineering sessions. Includes guided prompts for failure triage and release auditing.
Updated 20 hours ago (2026-10-01 18:49 UTC)
10
1,118 npm
738 PyPI
518
Apache 2.0
L-Dopa
Autonomous Agents Developer Tools
mshanghai570
A
license
A
quality
C
maintenance
It enables AI agents to recover from failures by diagnosing issues, refocusing broad tasks, restoring session context, and managing retries safely with bounded memory and credential redaction.
Updated a month ago (2026-08-27 19:09 UTC)
6
1
MIT
Casebook MCP
Search AI & Machine Learning
AgentPostmortem
A
license
Not graded
quality
B
maintenance
Enables agents to query a registry of documented AI-agent failures for debugging incidents, deployable on Cloudflare Workers.
Updated 20 days ago (2026-09-12 14:11 UTC)
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Publisher details

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources