浏览 MCP与Skills教程与资源
MCP 404、429 与超时：区分端点、限流和结果未知
从真实请求所在层定位故障，解释 GET 测试为何可能误导、协议版本为何影响 404，以及写操作超时后为什么必须先回读状态。
保留最后一条失败请求，别把三次不同失败拼成一个原因
一次修改 URL 后出现 429，再加大超时后断线，是三条不同请求。需要分别记录时间、最终端点、客户端/Server 版本、传输、请求方法、状态、耗时和工具是否有副作用，不能把后一次现象拿来解释前一次。
HTTP 状态可能来自反向代理、MCP Server 或工具访问的下游。外层 200 中的工具错误也可能包含下游 429。先标清层级，再判断改路由、降并发还是等待上游恢复。下面没有虚构某次线上故障时间线。
先辨认端点错误、协议方法错误和资源不可见
| 实际证据 | 判断方向 | 下一步 |
|---|---|---|
| 访问返回普通网站的 HTML 404 | 请求可能进了页面站点或错误代理路由 | 核对官方 MCP URL、末尾路径和重定向后的域名；比较服务端访问日志 |
| 浏览器 GET 失败，MCP 客户端 POST 能调用 | 服务可能只提供对应版本所要求的 POST 端点 | 以真实 MCP 请求判断；浏览器地址栏不是通用健康检查 |
| 2026-07-28 请求的 JSON-RPC 错误为 -32601 | 按该版规范可能是方法不支持，不能只凭外层 404 判断 URL 不存在 | 比对实际 method、协议版本和 Server 能力，使用兼容客户端复测 |
| 旧版有状态 HTTP 连接携带 session ID 后 404 | 仅在 2025 系列等支持协议会话的实现中，可能是 session 已失效 | 按该版本客户端流程重新建立会话；不能把旧 session 处理套在无协议会话的新版本上 |
| MCP 工具内部读取某个私有对象返回 404 | 可能真不存在，也可能提供方隐藏无权资源 | 检查同身份对该对象的权限与完整 ID；不要因此改 MCP endpoint |
Streamable HTTP 的 2026-07-28 修订移除了旧的协议级会话和 GET stream；网站地址不变不代表双方使用同一协议版本。
先找限流的是哪个服务，再决定等待方式
等待值来自响应，不来自猜测
有 Retry-After 时按它指示等待。这个头既可能是秒数，也可能是 HTTP 日期；不要一律 parseInt 后当毫秒。还要查看提供方的速率头和错误正文。GitHub 的主限流与次级限制就不是同一个判断入口，某些限制会返回 403。
降低放大倍数
Agent 一次任务可能触发多页搜索、评论分页和自动重试，多个客户端再并行会放大流量。先停掉重复任务，限制并发，减少不必要分页；不要每个工作线程独立按相同节奏重试。多个请求同时醒来会再次撞上同一限制。
给自动重试一个明确预算
例如对无副作用的读取，最多追加两次重试，遵守服务要求并加入随机延迟；达到次数或总耗时上限就返回暂不可用。这个次数是应用策略示例，不是 MCP 规范要求。没有 Retry-After 时按提供方建议退避，不能把自己的固定间隔当成对所有服务都合适。
总时限调大前，先找谁先停止等待
| 阶段 | 可观察证据 | 有针对性的处理 |
|---|---|---|
| DNS / TCP / TLS | 连接尚未进入 Server 日志；解析、连接或证书错误 | 核对域名、代理和证书链；工具 timeout 不是解决此层的唯一配置 |
| Server 启动 | 本地 stderr 显示包下载/初始化，尚未提供工具 | 先解决依赖和启动方式，再评估启动时限 |
| 客户端等待工具 | 客户端先报超时，Server 随后仍有处理记录 | 检查工具时限；缩小请求并查询是否已有结果，避免重复写 |
| Server 等待下游 | Server 日志明确是数据库、浏览器或 API 请求超时 | 分析下游耗时、查询计划或服务故障；仅增加客户端等待未必有用 |
| 代理 / 流式连接 | 流被固定时长切断或事件成批到达 | 核对代理空闲超时与缓冲；有同一请求的前后日志才能证明所在层 |
创建操作超时后，状态是未知，不是失败
查询 Issue #42 超时
可以在授权范围不变、限流允许、次数受限的前提下重试读取。但仍可能消耗配额或产生计费；只读不代表免费。恢复后说明结果来自哪次请求。
向 Issue #42 发布评论超时
评论可能已创建，只是返回丢失。先读取 #42 的近期评论，核对作者、内容和时间窗口，再决定是否重试。没有幂等机制且无法确认状态时，保留‘结果未知’并交给操作者，不能自动再发一遍。
JSON-RPC id 用于关联请求和响应，不是业务幂等键。即便重用同一个 id，也不能假定服务会去重评论、付款或创建记录。
用原请求复测，才能证明修复覆盖了原问题
修复路径后，复测原 endpoint 和同一只读动作；限流恢复后，保留等待值与新的请求频率；超时缓解后，说明请求是否被缩小以及业务结果是否完整。把 LIMIT 从 1000 改成 10 后成功，只证明小请求可用，不能宣称原全量任务已经完成。
服务端记录拿不到时，保留客户端能观察到的事实即可。例如‘代理返回 504，尚无法判断下游是否完成’，比编造上游 30 秒日志更有用。问题报告应帮助下一位维护者复现，而不是用完整表格遮住证据缺口。