为了让 AI 助手（如 ChatGPT、Claude、Cursor、CodeBuddy 等）能够稳定、准确地调用本站的探测能力，我们对平台的机器可读表达层做了一轮系统性补齐。本次更新不改变任何人工使用方式，全部为新增能力，对现有页面与接口完全兼容。

一、新增 MCP 服务：AI 可以直接"调"本站，不必再"爬"

我们已上线 Model Context Protocol（MCP）服务，接入地址为 POST /mcp，采用 JSON-RPC 2.0 协议，单次请求单次响应。支持 initialize / tools/list / tools/call 三个标准方法。

通过 MCP 暴露 5 个工具，名称与本站工具页一一对应：

  • ping：多节点 ICMP 延迟、丢包率与抖动检测
  • tcping：TCP 端口连通性与连接耗时检测（需 port 参数）
  • http：HTTP(S) 状态码、响应时间与下载速度检测
  • traceroute：逐跳路径追踪，返回每跳 IP、延迟与归属
  • dns：多节点 DNS 解析，支持 A / AAAA / CNAME / MX / TXT / NS / PTR / SRV

这意味着：接入方不再需要自己实现"创建任务 → 轮询状态 → 取回结果"三步流程，调用一次工具即可拿到全部节点的汇总结果。MCP 服务端已代为完成轮询与结果聚合，并做了并发控制（默认同时最多 4 个探测任务），避免触发整站限流。

工具返回值同时包含两份内容：content（文本摘要，直接读入上下文，节省 token）与 structuredContent（结构化 JSON，等价于 ?format=json）。前者便于模型理解，后者便于程序解析，按需取用。

二、新增 /llms.txt：把能力写清楚给 AI 看

新增能力契约文件 /llms.txt，以纯文本形式向 AI 声明本站提供什么、怎么调、注意什么，内容包括：

  • 五个工具及对应 API 端点
  • 逐工具参数表：参数名、是否必填、默认值、可选值一应俱全，AI 无需再去逆向前端脚本
  • 异步轮询的三步流程说明
  • 结果引用的四种 URL 形态
  • 限流规则与使用注意事项
  • MCP 接入方式

之所以要做这份文件，是因为过去 AI 首次调用常因参数名不一致而失败——例如 DNS 端点曾只认 domain，而其它工具用 target。本次已统一参数契约：五个端点一律优先接受 target，DNS 的 domain 作为旧名保留兼容；批量端点统一使用 targets[]，旧的 targets 写法继续可用。

三、结果导出：为机器消费优化的三种格式

每个探测任务的结果都可通过 permalink 以多种格式取回，均无需登录、无需鉴权，且全部带 X-Robots-Tag: noindex，不会被搜索引擎收录：

  • /result/{task_uid}?format=json：结构化数据，含 schema_version 契约版本号（当前为 2）
  • /result/{task_uid}?format=txt：纯文本，固定列序，token 开销约为 JSON 的三至四成
  • /result/{task_uid}?format=csv：表格格式，便于导入 Excel 等工具
  • /result/{task_uid}：人类可读页面

其中新增的 机器可读状态码 results[].status 尤为关键：取值为 ok（成功）、timeout（超时）、unreachable（目标不可达）、dns_fail（域名解析失败）、refused（端口拒绝连接）、error（其它失败）。此前只有成功布尔值与中文错误描述，调用方必须靠关键词匹配甚至正则来判断失败类型，极易误判；现在可直接按枚举值分支处理，且该取值集合一经发布即视为契约，只增不改。

四、工具页面向机器可读做了强化

五个工具页（ping / tcping / http / dns / traceroute）的结果表格均新增了结构化标注：

  • 行级 data-* 属性全覆盖：每行结果都带 data-status、data-node-id、延迟（平均/最小/最大）、抖动、丢包率等属性，数值一律不带单位（如 38.2 而非 38.2ms），便于直接计算。各工具还带有专属属性，例如 tcping 的 data-port、http 的分段耗时与状态码、dns 的记录类型与条数、traceroute 的跳数信息。
  • 表格语义化：每张结果表都带 <caption> 说明用途，每个表头带 scope="col"，使结构化解析与辅助技术都能正确理解表格结构。
  • 结构化数据：五个工具页均注入 WebApplication 类型的 JSON-LD，全站带 BreadcrumbList，内容页带 Article / NewsArticle。

这些标注让"抓取页面"与"调用 API"得到完全一致的结论——同一份结果，无论从哪个入口读取，状态判定口径都相同。

五、对 AI 爬虫的收录策略

我们在 robots.txt 中显式放行了主流 AI 爬虫（GPTBot、OAI-SearchBot、PerplexityBot、CodeBuddyBot），使本站工具页能够被 AI 正确检索与引用。

需要特别说明的是：结果页 /result/ 对包括 AI 爬虫在内的所有爬虫一律禁止抓取。这是因为结果 URL 本身就是访问凭证，task_uid 为随机高熵值，放开抓取等于把用户的私有测试结果公开出去。AI 需要的结构化能力，我们通过 /llms.txt 与 MCP 服务提供，这两条通路是显式、受控的，不存在意外泄露风险。

六、既有能力保持不变

以下能力此前已可用，本次一并说明，便于集成方了解全貌：

  • 所有工具 API 匿名可调，无验证码、无登录墙
  • 异步任务模型：POST /api/tool/{tool} 创建任务，GET /api/task/status?task_uid= 查询进度，GET /api/task/result?task_uid= 获取结果
  • 任务状态枚举：pending / dispatching / running / completed / failed / expired / cancelled
  • 整站限流：每 IP 每分钟 300 次；归属地查询接口每分钟 60 次；登录与注册接口每分钟 40 次
  • 站点地图 /sitemap.xml 动态生成，包含静态页、帮助、新闻、教程与探测收录页五个段落，均带 lastmod

七、关于后续规划

本期改动没有增加新的探测能力，做的是"让已有能力更好被机器读到"——统一参数契约、补齐结构化属性、提供机器可读状态码、开放标准调用协议。这类改动降低的是每一次调用的失败概率，收益体现在集成的稳定性上。

关于"历史与时序查询"（即让 AI 能回答"某站点最近一周是否稳定"，而不仅是"此刻是否通畅"），经评估该能力需要新建"按目标反查"的数据通路，会改变现有以高熵 UID 寻址、不可枚举的结果模型，存在数据暴露面的风险。因此该能力暂缓实施，待安全评估完成后再行推进。我们会在评估有结论时另行公告。

后续计划还包括输出 OpenAPI 3.0 规范，方便非 MCP 的通用集成方生成 SDK。

结语

本次更新后，本站从一个"AI 可以爬取"的工具站，升级为"AI 可以直接调用"的诊断服务。欢迎各位开发者通过 MCP 或 HTTP API 将本站能力集成到自己的监控、工单与自动化流程中。

使用中如有任何问题或建议，欢迎通过"反馈建议"联系我们。