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

The description mentions that the query is for the '近两年' (last two years) and returns aggregated text for total/production/sales/dependent types, adding behavioral context beyond annotations. Annotations only include openWorldHint:true, so the description does not contradict them and adds some context about the time filter and grouping, but it does not detail additional behavioral aspects like data freshness or limitations.

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?

Description is concise and well-structured: starts with the core function, then lists included metrics, exclusions, and example questions. It is informative without being verbose, though the pricing information is not directly relevant to tool selection and could be considered extraneous, but it does not harm the description's clarity.

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 a clear scope with explicit inclusions and exclusions, and the parameter schema is complete (100% coverage). The description covers key aspects: what it returns, what it excludes, and typical usage examples, making it adequate for an agent to understand purpose and usage. It could mention whether the return is a single number or a breakdown, but the description notes it returns text of totals, which is sufficient.

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 parameters are fully documented in the schema with examples for region, chain_name, and year. The description adds examples of typical queries and clarifies that year is optional, but it does not significantly enrich parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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?

Description clearly states the tool counts companies with external financing in the last two years, categorized by region and industry chain, and specifies the return includes totals for production, sales, and dependent types. It explicitly mentions what is not included (other categories, company lists) and distinguishes from sibling list tools, providing clarity on its aggregation function.

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?

Description includes typical question examples and specifies the parameters (region, chain name, year) which implies when to use it. It does not explicitly name alternatives, but among the sibling tools, it's clear this is the count version of the list tool (chain_invested_company_list), and the description's focus on aggregated counts and non-inclusion of lists provides context. Missing explicit when-not to use, but implicit differentiation is sufficient.

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