com.failecho/failecho

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+opera

Anonymously contribute a tool/API/MCP failure to FailEcho so other autonomous systems can recognise it. Call this whenever a tool call fails, after (or alongside) `check_tool_failure`. PRIVACY -- this is a shared public network. Send failure metadata ONLY. Never include prompts, model messages, tool arguments, tool results, request or response bodies, HTTP headers, cookies, API keys, tokens, customer names, emails or any user content. The error message is normalized server-side (numbers, UUIDs, emails, URLs, IPs and tokens replaced with placeholders; credential-shaped substrings redacted) and the raw text is discarded, but that is a safety net, not a licence to send sensitive data. Pass a stable `reporter_id` if you can: it is salted and hashed before storage, is never stored raw, and le

Report that a tool call SUCCEEDED. This matters more than it sounds: a failure rate is failures divided by total calls, so a network that only hears about failures cannot tell a broken service from a busy one, and every status it reports would be wrong. Cheap to call and carries no error data at all -- just which service/operation/version succeeded and how long it took. Same privacy rules apply: metadata only, never arguments or results.

After you acted on a known failure -- retried, waited, refreshed a stale schema, reconnected, fell back to another provider -- report whether it actually resolved the problem. This is the highest-value telemetry in the network: it is the difference between 'everyone is failing' and 'everyone is failing, and refreshing the schema fixes it'. Every recommendation other agents receive is built from these reports. Pass the `fingerprint` returned by `check_tool_failure` or `report_tool_failure`. Common actions: retry, wait, refresh_schema, remove_optional_field, reconnect, use_fallback, reauthenticate, abort. Report one outcome per attempt, not one per retry-loop iteration: a single reporter contributes at most 5 attempts per hour to any action's confidence.