关于 failshare
failshare 是连接 FailEcho 托管 MCP 服务的本地桥接程序,为 Agent 汇集工具、API 和 MCP 调用失败信息。Agent 可在重试前查询已知故障,并报告失败、成功及恢复结果,以支持后续建议。
主要功能
- 01查询共享故障状态
- 02查看恢复操作及成功率
- 03报告工具调用成败
- 04记录恢复结果
- 05仅发送故障元数据
适用场景
- 01重试前检查 API 超时
- 02报告工具调用失败
- 03比较恢复操作
- 04记录重试是否成功
MCP 相关
它通过本地 stdio MCP 服务暴露 FailEcho 托管的工具,并将调用转发至上游。结果原样返回。
配置
本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。
工具
4收录的工具列表 · 更新于 1 周前
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| service | string | 是 | MCP 服务自身的名称(serverInfo.name)或 API 主机名,例如 'api.github.com'。不是客户端的本地别名。 |
| verbose | boolean | 否 | 完整记录(时间戳、速率、有效计数、所有操作)。默认:简要答案。 |
| version | string | 否 | 服务/工具版本(如果已知)。 |
| operation | string | 是 | 服务器命名的工具或端点,例如 `create_issue`,而不是 `mcp__github__create_issue`。 |
| error_code | string | 否 | 代码,例如 `422`、`ECONNRESET`。 |
| error_type | string | 否 | 故障类别,例如 `validation_error`、`timeout`、`rate_limit`、`auth_error`。 |
| reporter_id | string | 否 | 可选的稳定 Agent ID;经过哈希处理,绝不存储原始值。这样才能回答 from_other_agents。 |
| schema_hash | string | 否 | 所用工具架构的短哈希(用于区分“API 故障”和“架构过时”)。 |
| error_message | string | 否 | 仅限错误文本;由服务器端规范化,此调用不会存储原文。 |
详细介绍
failshare
failshare 是一个小型本地桥接程序,用于连接 FailEcho 托管的 MCP 服务,这是一个供 Agent 共用的失败知识库。 当工具、API 或 MCP 调用失败时,Agent 会在盲目重试之前, 先查询网络中是否已有关于该确切故障的知识;它们也会报告 自身的失败、成功和恢复结果,以便下一个 Agent 获得更好的答案。
桥接程序不会保存任何失败数据,也不会自行进行计算。 它会在本地提供上游服务的工具列表,内容与从实时端点 捕获的完全一致,并将每次工具调用转发到上游,原样返回 结果。
工具
check_tool_failure- 在重试之前,查询网络中关于 某项故障的已知信息。返回状态 (HEALTHY / DEGRADED / MAJOR / INSUFFICIENT_DATA)、 计数、已奏效的恢复操作及其 成功率,以及一条建议。必需参数:service(服务器自身名称或 API 主机)和operation(服务器为工具或端点命名的名称)。可选上下文:error_type、error_message、error_code、version、schema_hash、reporter_id,以及用于返回 完整记录而非简要答案的verbose。report_tool_failure- 报告调用失败,以便 其他人能够识别此故障。必需参数:service、operation。可选参数:error_type、error_message、error_code、version、schema_hash、latency_ms和reporter_id。仅发送失败元数据—— 绝不要发送提示词、参数、结果、标头或密钥; 错误文本会在服务器端进行规范化处理。report_tool_success- 报告调用 成功。失败率需要分母:只听到失败的网络无法区分 服务故障和繁忙。必需参数:service、operation。可选参数:version、schema_hash、latency_ms、reporter_id。report_recovery_outcome- 对故障采取措施后 (retry、wait、refresh_schema、reconnect、 use_fallback、reauthenticate),报告措施是否奏效;所有 建议都基于这些报告生成。 必需参数:fingerprint(来自check_tool_failure或report_tool_failure)、action和successful。可选参数:reporter_id。
配置
FAILECHO_MCP_URL(可选)- 覆盖上游 端点。默认值为https://failecho.com/mcp。 (此覆盖钩子是本次重建中自行标注的内容。)FAILECHO_REPORTER_ID(可选)- 设置后,每个上游 请求都会携带一个X-Reporter-Id: <value>标头,其中包含该值。 未设置时,则不会发送此类标头。(此 转发功能同样是本次重建中自行标注的内容;原始接口是在无密钥情况下捕获的。)
转发机制
首次调用工具时,客户端会与上游建立一个可流式传输的
HTTP 会话:发送 JSON-RPC initialize
请求(protocolVersion 为 2025-03-26,clientInfo name
为 failshare),然后发送 notifications/initialized
通知,最后发送携带调用方原样参数的 tools/call 请求。上游在
initialize 响应中返回 Mcp-Session-Id 标头时,
该值会附加到此会话之后的每个请求中;此会话会在进程
运行期间重复使用。响应
可能是纯 JSON,也可能是服务器发送的事件;
两种格式都会读取。
上游成功结果会原样传递,
包括上游设置的任何 isError 标记。
失败——JSON-RPC 错误、非 2xx 状态、无法读取的响应,或
无法完成的请求——会以 isError 结果返回,其
文本以 failshare error: 开头(此呈现方式
是本次重建中自行标注的内容)。
CLI
每个工具也都是一个子命令,接收一个 JSON 参数 字符串:
npx @reneturcios/failshare check_tool_failure '{"service":"api.github.com","operation":"create_issue","error_type":"timeout"}'
npx @reneturcios/failshare report_tool_failure '{"service":"api.github.com","operation":"create_issue","error_type":"validation_error"}'
npx @reneturcios/failshare report_tool_success '{"service":"api.github.com","operation":"create_issue","latency_ms":42}'
npx @reneturcios/failshare report_recovery_outcome '{"fingerprint":"0123456789abcdef0123456789abcdef","action":"refresh_schema","successful":true}'
npx @reneturcios/failshare --version
退出代码:成功时为 0,返回 isError
结果时为 1,用法错误时为 2。
MCP 服务
npx -y @reneturcios/failshare mcp
MCP 客户端配置:
{
"mcpServers": {
"failshare": {
"command": "npx",
"args": ["-y", "@reneturcios/failshare", "mcp"]
}
}
}
Docker
docker run -i ghcr.io/cloudcorprecords/failshare
docker run --rm ghcr.io/cloudcorprecords/failshare --version
容器的默认命令是 mcp,因此第一种形式是 stdio MCP 服务;其他参数则会照常传递给 CLI。
开发
npm install
npm run build
npm test
npm run dev
测试套件完全针对存根 JSON-RPC 上游运行,不会发起任何实时网络调用。
许可证
MIT - 详见 LICENSE。
评论
一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。