审计一个网站/页面能否被中文 AI 搜索（豆包、DeepSeek、文心、Kimi 等）抓取、解析与引用。
一次抓取完成六层检查：可抓取（含中国爬虫矩阵与边缘层拦截实测）、可解析、可引用、
实体一致、分发、可信可自验；返回 0-100 分与 A-F 等级、逐项证据、优先修复清单。
用途场景：客户站点体检、上线前自检；传 compare_with 可做竞品对比（逐层与逐项差异）。
注意：只做确定性检查，不调用大模型；评分口径见 scoring_version。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| include_raw | No | ||
| compare_with | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description discloses that a single fetch performs six deterministic checks, includes real interception testing of Chinese crawler matrices, intentionally does not call an LLM, and reports according to scoring_version. These are useful behavioral traits not inferable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact, well-structured paragraphs front-load the core action, then layers, output, use cases, and caveats. No fluff; every clause adds operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex audit tool, the description covers the six check layers, the 0-100/A-F output, evidence and priority-fix list, compare_with mode, determinism/no-LLM behavior, and scoring-version reference. The only notable gaps are include_raw semantics and sibling-tool routing, which keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It gives meaning to url (the site/page being audited) and compare_with ('传 compare_with 可做竞品对比（逐层与逐项差异）'), but leaves include_raw entirely undocumented, so an agent cannot tell whether raw means raw evidence, raw HTML, or raw response scores.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb-resource pair—'审计一个网站/页面能否被中文 AI 搜索…抓取、解析与引用'—and enumerates six specific check layers plus the score/grade output. This clearly differentiates it from inspection-style siblings like plan_fixes and score_visibility, even though those names aren't explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States explicit use scenarios ('客户站点体检、上线前自检') and describes the compare_with competitive-comparison mode. It doesn't name sibling tools as alternatives or list when-not-to-use cases, so it stops at clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.