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

Annotations only include openWorldHint=true, which doesn't convey much about safety (read vs. write). The description adds that it returns a list (not a count) and excludes other categories, but doesn't clarify performance characteristics, pagination, or any potential side effects. Given the sparse annotations, more behavioral disclosure would be beneficial, but the basics are covered.

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, with a clear main line, a list of exclusions, and example queries. The pricing information is included (although not strictly part of the description, it's structured separately). No fluff or redundancy; every sentence adds value. Slightly less ideal because it lacks a summary of return format, but it's well-organized.

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?

The tool has an output schema, so return type is documented. Given the moderate complexity (2 params, 1 required), the description covers the purpose and typical usage. However, with openWorldHint=true, the description could mention that the list might include companies beyond a fixed set or require flexible matching, but it doesn't. It lacks details about potential edge cases (e.g., what happens if park_name is ambiguous).

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 both parameters (park_name, year) are documented in the schema. The description adds context by showing typical examples (园区名称, 年份), but doesn't add meaning beyond the schema itself. The baseline for high coverage is 3, and no additional insight is provided.

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 purpose: '基于具体园区名称拥有专利的企业列表查询' (query company list with patents based on a specific park name). It specifies that it returns a list of companies, not just a count. While it distinguishes from the 'num' variant (park_have_patent_company_num), it doesn't explicitly contrast with the 'chain_' prefix variants (which likely relate to a different geographic scope, but the description doesn't clarify this).

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 provides typical usage questions, which gives context for when to use it. However, it doesn't explicitly state when NOT to use this tool vs. alternatives like the chain_* variants or the *_num variants. The '不包含' section notes exclusions (e.g., other company categories), but lacks explicit comparisons to sibling tools.

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