failecho

Check what the network knows about a tool failure

check_tool_failure

Use FailEcho when another tool fails, before retrying blindly.

Use this tool when another tool, API call, or MCP server operation fails. It checks whether other autonomous systems recently experienced the same failure and returns current failure intelligence, known recovery actions, and confidence based on observed outcomes.

Call it BEFORE retrying. A retry that is failing for every other agent right now is a retry you can skip, and the network often knows a specific action that works instead (refresh a stale tool schema, fall back to another provider, reconnect, wait).

Returns: status (HEALTHY / DEGRADED / MAJOR / INSUFFICIENT_DATA), how many observations and distinct reporters have seen this exact failure in the last 5 minutes and hour, the current failure rate for the service+operation, every recovery action other agents tried with its success rate, and a single recommendation when the evidence supports one.

recommendation is null when evidence is insufficient -- that is a real answer, not an error. Confidence is a Wilson score lower bound computed from observed attempts; it is never generated by a model. Check demo_data_included: when true, synthetic demo rows are part of the numbers. evidence_sources says who saw it: 'agent' means independent agents; 'first_party' alone means only FailEcho's own agents, so weigh it as one reporter's experience.

Reading is free, anonymous, unauthenticated and never rate limited, and this call stores nothing.

Input Schema

TableJSON Schema

Name	Required	Description
`service`	Yes	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.
`version`	No	Version of the failing service/tool, if known.
`operation`	Yes	The tool or endpoint exactly as the server defines it, e.g. 'create_issue' -- without client prefixes such as 'mcp__github__'.
`error_code`	No	Protocol/vendor code, e.g. '422', 'ECONNRESET'.
`error_type`	No	Short failure class, e.g. 'validation_error', 'timeout', 'rate_limit', 'auth_error'.
`reporter_id`	No	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.
`schema_hash`	No	Short hash of the tool schema you used. Lets FailEcho separate 'the API broke' from 'your tool schema is stale'.
`error_message`	No	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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 11, 2026

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."

First observedSep 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden and does: read-only, free, anonymous, unauthenticated, never rate limited, stores nothing, plus null-recommendation semantics, Wilson-score confidence provenance, demo_data_included, and evidence_sources weighting. This is unusually complete disclosure for a tool with zero annotation coverage.

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?

Front-loaded with the trigger and the pre-retry rule, then structured into behavior and return-field paragraphs, all of which are substantive. It runs long, and the return-value paragraph partly duplicates an output schema that already exists, costing it the top mark.

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?

An 8-parameter, evidence-interpretation tool with an output schema; the description supplies the interpretive context an agent needs (what HEALTHY/DEGRADED mean, when recommendation is null, how to weigh first_party vs agent sources) rather than relying on raw fields. Nothing needed to call it correctly 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 description coverage is 100% and the parameter docs are detailed (naming conventions, redaction, schema_hash purpose), so the schema already does the heavy lifting. The description itself adds almost nothing about parameters beyond reinforcing 'service + operation' — baseline 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?

States a specific verb and resource ('check whether other autonomous systems recently experienced the same failure' and return failure intelligence), and its 'reading is free... stores nothing' framing implicitly separates it from the report_* siblings, which are writes. An agent can tell what this does 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?

Explicit trigger ('when another tool, API call, or MCP server operation fails'), explicit ordering ('call it BEFORE retrying'), and an explicit alternative — blind retry — with the condition that makes skipping it correct. Nothing about when to invoke is left to inference.

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

All failecho tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.