Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail beyond that: it produces per-question breakdowns, original excerpts for client self-verification, live URL accessibility checks when verify_citations=True, and extracted numeric claims marked as unverified. This is consistent with the annotations and discloses important external-check behavior.

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?

The description is long but dense and every sentence earns its place: overview, sample JSON template, methodology note, output contents, and optional flag behaviors. The critical invocation details are front-loaded, and the inline JSON example is an efficient substitute for missing schema descriptions.

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?

Given the complexity of a nested JSON-string input and zero schema field descriptions, the description is complete enough for correct invocation. It covers required input structure, suggested sampling frequency, output composition, and optional verification modes. An output schema exists, so the description is not obligated to enumerate every return value.

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%, but the description fully compensates by embedding the exact JSON structure for the samples string, including all relevant fields, enums for role/sentiment/facts, arrays, and the date format. It also explains the two optional boolean parameters and their effects. This is strong parameter-level guidance where the schema itself provides none.

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 clearly states the tool's core operation: '按五大核心指标 + 语义角色分权，计算 AI 搜索可见度并输出可自验的测量报告'. This is a specific verb and resource, and the tool is clearly a measurement/reporting tool rather than a fixer or auditor. However, it does not explicitly contrast itself with sibling tools such as audit_cn_citability or plan_fixes, so it misses full sibling differentiation.

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?

The description gives concrete usage guidance: samples must be a JSON string, multiple rounds are recommended ('每题建议多轮（同一问题重复 7-8 次）'), and it explains what happens when verify_citations or extract_claims are enabled. It does not explicitly state when this tool should be preferred over alternatives or when it should not be used, so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.