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

Annotations only include openWorldHint: true, which the description does not contradict. The description adds behavioral details: it returns a merged text of total/production/sales/dependent types and explicitly states it does not return only counts. However, it doesn't disclose limitations or additional behaviors like pagination, sorting, or potential empty results, though openWorldHint partially covers exhaustiveness.

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 front-loaded with the core purpose. It includes exclusions and typical queries in a structured way. Though it has some redundancy with the schema, it's not overly verbose and each sentence adds value.

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 and the presence of an output schema, the description is reasonably complete. It covers purpose, returned data types, exclusions, and examples. It lacks details on output format specifics, but the output schema compensates. It could mention limitations like data freshness or coverage, but overall it's sufficient for an agent to decide correct usage.

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 coverage is 100% with descriptions for all three parameters. The description adds extra semantic value by clarifying region granularity (national, province, city, district) and chain name examples, and typical query examples illustrate parameter usage. This goes beyond the schema's simple examples, providing more guidance.

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 states the tool's purpose clearly: query a list of specialized and refined companies based on a specific region and industry chain. It explicitly lists the included types (total/production/sales/dependent) and excludes other classifications and count-only results. It also provides typical query examples, distinguishing it from sibling tools like chain_specialized_company_num and other chain_*_company_list tools.

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 clear context on what it returns (a list, not counts) and what it excludes (other enterprise classifications). While it doesn't explicitly name alternative tools, the exclusion of count-only and other types implies when to use this vs. the _num variants or other list types. Typical queries help guide usage for region and chain inputs.

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