FailEcho

Official

Overview Schema Source Related Servers Discussions Admin

Check what the network knows about a tool failure

check_tool_failure

Checks live cross-agent failure fingerprints before retrying a failed tool or API call, returning known recovery actions and confidence from observed outcomes. Call it after failures to avoid blind retries.

Instructions

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.

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

Input Schema

TableJSON Schema

Name	Required	Description
`service`	Yes	Tool/service identifier, e.g. 'github-mcp'.
`version`	No	Version of the failing service/tool, if known.
`operation`	Yes	Operation/tool name that failed, e.g. 'create_issue'.
`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.

First observedv0.1.0Sep 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure, and it delivers comprehensively: the call is 'free, anonymous, unauthenticated and never rate limited, and this call stores nothing.' It also discloses semantic edge cases ('recommendation is null when evidence is insufficient -- that is a real answer, not an error'), statistical methodology ('Wilson score lower bound... never generated by a model'), and the demo-data caveat ('synthetic demo rows are part of the numbers').

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 front-loaded with purpose and trigger conditions, then organized into logical blocks (when to use, what it returns, semantics of null/confidence/demo data, privacy guarantees). It is longer than typical, and the Returns paragraph partially re-describes what the output schema already enumerates, but nearly every sentence carries distinct information, and the length is justified by the tool's trust-sensitive nature.

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?

For an 8-parameter, no-annotation tool accepting error messages and reporter identifiers from an external network, nothing needed for correct invocation is missing: trigger conditions, return contract, null semantics, statistical integrity, demo-data contamination, and privacy/rate-limit guarantees are all covered. The presence of an output schema further covers return structure, and even so the description explains the non-obvious interpretation rules.

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 schema already documents all 8 parameters, warranting the baseline of 3. The description adds some contextual framing (e.g., schema_hash lets FailEcho separate 'the API broke' from 'your tool schema is stale', and error text is normalized and redacted server-side), but these details are also present in the schema itself. The description does not compensate for any gap because there is no gap.

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 opens with a specific, concrete definition: 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.' The verb+resource is precise, and the tool is clearly differentiated from the report_* siblings by being the pre-retry query tool versus the post-hoc reporting tools.

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?

Usage guidance is explicit and actionable: 'Use this tool when another tool, API call, or MCP server operation fails. Call it BEFORE retrying.' It also names the alternative behavior it replaces ('a retry that is failing for every other agent right now is a retry you can skip') and the recovery actions the network may suggest. There is no ambiguity about when to invoke it.

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

Deploy Server