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

Annotations include only openWorldHint=true, which the description does not contradict. The description adds valuable context: it clarifies that the tool covers only '存量' (stock) indicators and excludes '新增' (new) registrations, which is a behavioral boundary not visible in annotations. It also includes pricing details and specifies that data versions are as per library, with mismatch flagged. This goes beyond the annotation's minimal info, though it doesn't elaborate on side effects (likely none, as it's a query).

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 concise and well-structured: the core functionality is in the first two sentences, followed by exclusions and examples. The pricing block is separate and clearly formatted, adding necessary cost info without clutter. No redundant sentences, but the pricing section could be considered verbose for a tool description, yet it's relevant for cost-aware agents.

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 tool's moderate complexity (3 parameters, output schema present), the description covers key aspects: scope, exclusions, typical usage, and pricing. It does not explain the return format, but that's handled by the output schema. The openWorldHint is minimal, but the description compensates by clarifying boundaries. It's adequate for an agent to understand tool capabilities and limitations.

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 100%, so the baseline is 3. The description adds examples of input_text ('武侯区本地注册企业数量') and clarifies that gov_names is optional for different scenarios. However, it does not add much beyond the schema's already detailed parameter descriptions, which include nested examples for gov_names. The pricing note is independent, not parameter-specific.

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 returns '存量规模指标' for companies/individuals/listed companies, with specific coverage (注册企业数量、密度、行业结构占比、平均注册资本). It distinguishes from the sibling 'gov_data_enterprise_change' by explicitly excluding 新增注册/注销/吊销 and pointing to that alternative. It also provides example queries, making the purpose unmistakable.

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 explicitly states when to use this tool (for 存量 indicators) and when not to (for 新增/注销/吊销, use 市场主体异动). It provides typical question patterns and clarifies the scope, which helps the agent choose between this and sibling tools. However, it doesn't mention alternatives like 市场主体异动 by name, but the pointer is specific enough.

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