SupplyGraph.AI Data

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

With only openWorldHint annotation (which doesn't describe safety/destructive behavior), the description carries the burden and does well: it discloses the input granularity constraints (must be a locatable point, not a region), the aggregated output nature (counts, not details), and pricing (100 credits/run). While it doesn't discuss data source, update frequency, or rate limits, these are largely orthogonal to the tool's observable behavior for an investigating agent.

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?

Although lengthy, every section earns its place: core definition, included metrics, explicit exclusions, typical queries, and pricing are clearly delimited with headers. The structure enables scanning and the examples are high-information. This is comprehensive specification, not bloat, and is appropriately sized for a complex geospatial query tool.

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?

For a tool with 2 parameters, an output schema, and moderate geographic/format complexity, the description is complete. It covers scope (China-only, specific-address queries), granularity constraints, inclusion/exclusion criteria, and provides multiple worked examples. Since an output schema exists, the description properly omits return-format details while all other operational aspects are well-specified.

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 detailed per-parameter descriptions (e.g., city without '市' suffix, structured address ordering rules). The description adds value beyond the schema through typical query examples that demonstrate correct parameter population (e.g., '北京市朝阳区阜通东大街6号周边有多少企业'), confirming the city/address split and the exact query type expected, going slightly beyond the baseline of 3.

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 uses a specific verb+resource structure: '查询...附近/周边的企业统计' (query surrounding enterprise statistics), and clearly distinguishes itself from siblings by specifying it returns aggregate counts (企业数量, 个体工商户数量, industry classification statistics), not name lists. The '不包含' (not included) clause explicitly excludes POI statistics and housing/population indices, which directly differentiates from siblings like cbd_surrounding_population and poi_data_shopping.

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 explicit when-to-use context (China-specific addressable points, statistical aggregation queries) and clear exclusions (no city/district names, no overseas addresses, no name details). It gives typical question patterns ('典型问法') to guide invocation. However, it doesn't name alternative tools by sibling name (e.g., 'use cbd_surrounding_population for population data'), relying on implied differentiation through the exclusion list.

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

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

The only annotation is openWorldHint:true, which is not contradicted. The description adds important behavioral context: it returns aggregate statistics, not raw lists, and clarifies that the address must be a specific point. It also discloses pricing (100 credits per run). However, it does not explicitly state whether the operation is read-only or if there are side effects, though '查询' implies read-only.

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 relatively long but well-structured: it starts with the core function, then clarifies exclusions, provides examples, and ends with pricing. Each section earns its place—the examples are particularly useful for agent usage. Slight verbosity could be trimmed, but it's not excessive for the tool's complexity.

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 presence of an output schema (not shown), the description does not need to detail return format. It covers the primary use case, constraints on inputs, and what is not included. The tool has only two required parameters, both well-documented. The description provides typical query examples and category breakdowns, making it adequately complete for an agent.

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% and both parameters have detailed descriptions. The description adds value by emphasizing that the address must be a specific location (not a city/county name) and provides examples of valid addresses. This guidance goes beyond what the schema states, helping the agent correctly populate the 'address' parameter.

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: to query surrounding shop statistics (counts by category) for a specific address in China. It specifies the resource ('店铺统计'), the verb ('查询'), and distinguishes from siblings by explicitly excluding detailed lists and other data types (e.g., companies, real estate). Examples of typical queries reinforce the purpose and differentiate from tools like business_surrounding_company.

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 clear usage context: must be a specific addressable point in China, not a city/county name, and excludes detailed shop lists. It gives typical query formats and explicitly states what is NOT included (e.g., business/individual counts, housing prices). However, it does not explicitly name alternative tools for those excluded use cases, so it stops short of a full when/when-not comparison with siblings.

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

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

Annotations only provide openWorldHint, so the description carries the transparency burden. It discloses that the output is aggregated analysis (star ratings and indices) rather than detailed lists, and explicitly lists excluded data types. It also includes pricing information. It does not discuss errors or rate limits, but the behavioral contract is well 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 structured into clear sections: core function, included metrics, exclusions, typical queries, and pricing. Every sentence adds useful information, and there is no filler or redundancy.

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?

For a 2-parameter tool with an output schema, the description is complete: it covers input constraints, output categories, exclusions, examples, and cost. The presence of an output schema means return-value details do not need to be repeated in the description.

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% for both parameters, so the baseline is 3. The description adds meaningful value beyond the schema by providing typical example questions and clarifying that the address must be a specific locatable point, not a city or district name, and not overseas. This extra context helps the agent map natural-language queries to parameters.

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 '查询其附近/周边的配套分析' for a specific China address, with explicit output categories (education/medical/shopping/transport star ratings and indices). It distinguishes itself from sibling tools by explicitly excluding housing prices, population counts, and detailed POI lists.

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 strong usage guidance: it requires a specific locatable address, forbids city/district names and overseas addresses, and gives typical question examples. It also lists exclusions ('不包含') that clarify when not to use the tool, though it does not explicitly name alternative sibling tools.

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

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

Annotations include only openWorldHint: true, which implies potential external effects but gives no specifics. The description adds valuable context about the output type (consumption level index/description) and explicitly excludes raw data, clarifying the tool's scope. However, it does not mention any side effects or mutation, which could be a gap if the tool triggers writes. The description’s clarification of behavior (what it returns and what it omits) earns a strong score, though not the highest due to missing side-effect disclosure.

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 reasonably concise given the complexity: it states purpose, coverage, exclusions, and typical questions in a structured way. While not ultra-short, every sentence contributes useful information (e.g., what is included, what is not, example queries). It is front-loaded with the core action and scope, making it efficient without being verbose.

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?

With an output schema present (not shown but indicated), the description need not explain return values. It covers what the tool does, what it returns (consumption index/description), exclusions, address requirements, and typical usage. For a two-parameter tool with full schema coverage and rich sibling context, the description is comprehensive and leaves no major gaps for an agent to choose and invoke correctly.

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 descriptions cover 100% of parameters, already explaining city format and address structure. The description adds extra guidance on address granularity (must be a specific point, not city/district) and provides multiple address examples, which reinforces the schema. It does not redefine parameters but adds contextual color that aids correct invocation, so it adds value beyond the schema.

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 queries surrounding consumption analysis for a specific address in China, returning a consumption level index and description, and explicitly lists exclusions (e.g., no per-capita expenses, POI lists). It differentiates from sibling tools (cbd_surrounding_amenity, housing, population) by focusing on consumption, making its purpose unambiguous.

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 explicit usage constraints: the address must be a locatable point within China (not a city or district name, no overseas), and typical question formats are given. It also lists what the tool does not include, guiding when to use it (for consumption level, not detailed data). This goes beyond basic context and offers actionable guidance for selection.

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

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

Annotations only include openWorldHint, with no readOnly or destructive hints. The description uses the verb 'query' (查询) and states it returns data, implying a read-only operation, but does not explicitly mention side effects, permissions, or that it makes no modifications. It provides clarity on what is returned but not on behavioral impacts beyond that.

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 fairly detailed but well-structured, with clear sections for what it returns, what it excludes, and typical queries. It is not overly verbose given the need to convey constraints and examples, but could potentially be tightened while preserving key information.

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 description is complete for a tool with two parameters and no output schema. It explains the purpose, input constraints, expected output (average price, trends, indices, suggestions), and what is not included, along with usage examples. This fully covers the context needed for an agent to use it correctly.

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?

The schema already describes both parameters with detailed constraints, but the description adds extra context about valid addresses (must be specific point in China, not city name) and provides concrete examples. This enriches the parameter semantics beyond the schema, which already covers 100% of parameters.

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 queries surrounding housing prices and investment analysis for a given address, and explicitly lists what it returns and what it excludes. It distinguishes from sibling tools by focusing on housing, with typical examples provided.

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 query examples and explicitly states what is not included (e.g., transaction details, amenities, population density), which helps differentiate when to use this tool over siblings like cbd_surrounding_amenity or cbd_surrounding_population. It could be more explicit about when to use it, but the examples and exclusions give clear guidance.

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

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

Annotations only declare openWorldHint=true, which is not very informative. The description compensates by disclosing scope limitations (China-only, specific point required, not city-level), what data it returns (indices and descriptions, not detailed lists), and what it excludes (household registration counts, POI names/coordinates). It clearly communicates it is a data query tool returning analysis rather than raw statistics. No contradiction with annotations.

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 somewhat lengthy, especially the list of excluded indicators and examples which could be trimmed. The core purpose is in the first sentence, but the pricing JSON and repeated exclusions add bulk. It is structured and front-loaded but includes redundant details (e.g., repeating China-only restrictions in both description and parameter schema).

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 has an output schema, return values are documented separately. The description covers input constraints, data types, exclusions, and examples comprehensively. With openWorldHint as the only annotation, the description effectively carries the behavioral burden. It is complete enough for an agent to correctly invoke it without further clarification.

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% with both parameters well-documented (city without 市 suffix, address with hierarchical structure rules). The description adds extra examples of valid address forms and reinforces the address scope constraints (China-only, no city names as address). It also clarifies the address format requirement beyond the schema alias example.

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 queries population analysis near a specific Chinese address, listing the three indicator types (人口结构, 居住密度, 商务密度) and explicitly excluding non-target data (户籍统计, 人口名单). It distinguishes from sibling tools like cbd_surrounding_consumption and cbd_surrounding_housing by specifying only population/density indices, not consumption or housing details.

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 specifies valid address types (门牌、地标、路名、小区名、园区出入口) and invalid ones (市名, 区县名, 境外地址), with typical question examples. It does not explicitly name alternative tools for other surrounding analyses, but the examples and exclusions provide clear usage context. No explicit 'when not to use' beyond scope exclusions, so a 4 is appropriate.

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

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

With only an openWorldHint annotation, the description carries the behavioral burden. It discloses the merged return format ('合并返回总量/生产型/销售型/依赖型文本') and scope exclusions, adding useful context beyond the annotation, though it does not mention auth, rate limits, or result details.

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 front-loaded with purpose, followed by a concise include/exclude list and example queries. The embedded Pricing JSON is arguably extraneous but not distracting; overall the content is efficient and well-structured.

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 schema and the clear sibling pattern, the description covers what the tool returns, what it excludes, and typical query phrasings. It does not discuss pagination or result limits, but the presence of an output schema likely covers return structure, making this sufficiently complete for selection.

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%, but the description adds value by specifying region granularity ('国家，省份，城市，区县'), concrete chain_name examples, and typical year usage via example questions, going beyond the schema's basic field descriptions.

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 a specific verb ('查询') and resource ('A级纳税人企业列表'), scoped by region and chain name. It also enumerates sub-types (total/production/sales/dependent) and excludes count-only queries, clearly distinguishing it from sibling *_num 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?

Usage is clear: use for region + chain name A-level taxpayer list queries. Explicit exclusions ('不包含：其他企业分类的统计；仅返回数量不返回名单') tell the agent when not to use this tool, though it does not explicitly name the alternative chain_a_taxpayer_company_num.

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

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

The description discloses that the tool returns aggregated counts as text and does not include company lists or other classifications. It also mentions the requirement for a specific region and chain name. There is no contradiction with the openWorldHint annotation, and it provides sufficient context for a read-only aggregation 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 moderately sized, with a clear structure: introduction, included metrics, exclusions, and typical examples. It is efficient and front-loaded, though it includes pricing information that might be redundant or belong elsewhere, but does not detract heavily.

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 (three parameters, output schema exists) and full schema coverage, the description is complete enough. It specifies the return type (aggregated text), examples, and exclusions. The output schema is not available but the description covers key aspects, making it sufficient for the agent.

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?

The schema covers 100% of parameters with descriptions, but the description adds value by clarifying that 'region' can be a national, provincial, city, or district-level name (examples like '全国', '成都'), and that 'chain_name' refers to industry chain or node names (e.g., '集成电路'). It also mentions 'year' as statistical year, though not detailed in the description but in schema.

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 function: to query the count of A-level taxpayer companies based on a specific region and industrial chain, returning a combined text of totals and types (production, sales, dependency). It includes specific metrics and typical examples, and distinguishes from sibling tools like chain_a_taxpayer_company_list by focusing on counts rather than lists.

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 strong usage guidance by listing what is included and excluded (e.g., excludes other enterprise classifications and company name details), which helps the agent decide when to use this tool. However, it does not explicitly mention alternatives or when not to use it, though the exclusion of company list details implies the list counterpart for detailed lists.

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

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

The annotation only includes openWorldHint: true, which is vague. The description explains that the tool returns a combined text of total/production/sales/dependent lists, and that it excludes other classifications. This is some behavioral context beyond annotations. However, it does not clarify whether the response is a single aggregated text or separate lists, or any pagination/limit behavior, but that might be in the output schema. No contradiction noted.

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, using bullet points for metrics and exclusions, and providing clear examples. Every sentence adds value, no fluff. It is front-loaded with the core purpose.

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 rich output schema (though not shown), and the description covers purpose, included metrics, exclusions, and examples. Given the complexity of the chain context and the availability of the output schema, the description is sufficiently complete. It does not explain the combined text structure in detail, but that may be covered by the output schema.

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?

The schema covers all parameters with descriptions. The description adds context by mentioning region granularity (country, province, city, district) and chain name examples, which align with the schema. Since schema coverage is 100%, baseline is 3. No additional syntax or format details beyond the schema, so score stays at baseline.

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 identifies the tool's purpose: querying a list of companies that closed in a given year, filtered by region and industry chain. It lists the included metrics/types (e.g., total, production-type, sales-type) and explicitly excludes other categories, distinguishing it from sibling tools like chain_close_company_num which returns counts.

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 query examples (e.g., '2024年全国集成电路当年注销的企业名单') which illustrate usage. However, it does not explicitly state when not to use this tool versus alternatives like chain_close_company_num (which returns only counts), though the examples imply that this tool is for lists. It lacks explicit exclusion guidance.

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

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

Annotations only include openWorldHint=true, which is vague. The description clarifies the return is a merged text of total/production/sales/dependent counts, which adds value. It does not mention any additional behavior like sorting, pagination, or error cases, but since the tool is a simple count query, this is acceptable. However, it could be more explicit about the output format (though the output schema exists).

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, front-loaded with the main purpose, and includes exclusions and examples. The pricing info is extraneous but not harmful. It is structured with clear sections, though the pricing block could be removed from the description as it is likely metadata.

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 it has an output schema, the description covers the essential aspects: what it returns (total/production/sales/dependent counts), region granularity, and typical queries. It does not explain edge cases like missing year (it's optional) but the schema does. Sufficiently complete for a simple count tool.

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?

The input schema covers 100% of parameters with descriptions (year, region, chain_name). The description adds nuance by explaining metrics included (生产型/销售型/依赖型) and gives examples of valid region values. However, it does not add major new meaning beyond the schema, so 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?

The description states it queries the count of companies closed in a specific region (country/province/city/district) and industry chain for a given year. It clearly differentiates from sibling tools like chain_close_company_list (list vs. count) and other chain_*_num tools (different metrics like patents, high-tech, etc.). The verb is specific: '查询...企业数量' with clear scope.

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 typical question examples ('典型问法') that illustrate when to use this tool (e.g., '2024年全国集成电路当年注销的企业有多少'). It also states what is not included ('不包含：其他企业分类的统计；企业名单明细'), which helps distinguish from list tools. However, it does not explicitly mention alternatives like chain_close_company_list for when a list is needed, but the exclusion and examples are sufficient.

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

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

Annotations only provide openWorldHint, so the description carries the burden; it discloses that output is merged text with totals/lists by type and explicitly excludes other category statistics/count-only responses. Read-only is implied by '查询' rather than explicitly stated, but no side effects are suggested.

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 front-loaded with purpose, includes examples, exclusions, and pricing, and is reasonably compact. The '仅返回数量不返回名单' phrase is awkward and slightly conflicts with the tool's list-oriented purpose.

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?

For a query/list tool with an output schema, the description sufficiently covers inputs, output categories, exclusions, and example phrasings. It is adequate for selecting among many sibling list/count tools, though it does not explicitly map to sibling names.

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 already covers all parameters (100%), but the description adds meaningful region granularity (国家/省/市/区县), chain-name semantics, and realistic examples. This enriches the schema rather than merely repeating it.

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 identifies a region + chain-name list query, enumerates output categories (total/production/sales/dependent) and gives typical examples. It does not explicitly compare to sibling list tools, and the '仅返回数量不返回名单' line creates some ambiguity for a tool named list.

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?

Typical questions and the region/chain criteria imply when to use, and exclusions such as '其他企业分类的统计' and count-only responses provide negative guidance. It stops short of naming alternatives like chain_company_num or the specialized list variants.

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

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

The description mentions it returns combined text of total/production/sales/dependent counts. It clarifies it does not include other classifications or company list details. The openWorldHint annotation suggests the data is open-world, which the description doesn't contradict. It doesn't disclose potential ambiguity in region names or year availability, but the basic behavior is transparent.

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. It starts with the core function in one sentence, then lists metrics, exclusions, and examples. Every line adds value; no redundancy or fluff.

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?

For a count-query tool with 3 parameters and a clear output schema, the description adequately covers the scope. It mentions typical questions, what's excluded, and the aggregation types. It doesn't describe output format, but with an output schema present, it's not heavily required. The optional year parameter is mentioned in schema but not in description examples; minor gap.

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% - all three parameters (year, region, chain_name) have descriptions in the schema. The description adds examples of valid values (e.g., '全国', '成都', '集成电路') and mentions year is optional. But it doesn't add much beyond the schema's descriptions.

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 states explicit purpose: query enterprise counts by region (country/province/city/district) and industry chain name, returning aggregated counts. Clearly distinguishes from sibling _list tools which return company details, and from other chain_*_num tools by the specific metrics (total/production/sales/dependent).

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 provides clear context: 'based on specific region and industry chain name', including typical query examples. It explicitly lists what is NOT included (other classifications, company name details), which helps avoid misuse. However, it doesn't explicitly state when to prefer this over sibling tools (e.g., chain_company_list) but the examples and exclusions make it clear.

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

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

The description mentions the open-world hint by stating outputs are combined text for total/production/sales/dependent types, and excludes other classifications. It does not contradict annotations, and adds moderate detail beyond the schema, but lacks information about pagination, formatting, or data source caveats.

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 reasonably concise, uses bullet-like structure for included types and exclusions, and provides clear examples. It could be slightly more compact, but the content is front-loaded and relevant.

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 has an output schema and full parameter coverage, the description sufficiently explains scope, exclusions, and typical queries. It is complete for selecting and invoking the tool correctly, though it lacks detail on output format details that might matter in edge cases.

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% for all three parameters, so the baseline is 3. The description adds example values and clarifies that year is optional, but does not go beyond the schema's parameter meanings.

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 discredited company lists filtered by region and industry chain, and specifies the aggregated sub-types (total/production/sales/dependent). It distinguishes itself from sibling tools like chain_discredited_company_num by noting it returns lists and counts, not just numbers.

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 query examples and states what is not included (other enterprise classifications, count-only results). However, it does not explicitly address when to use this list tool vs the num sibling, other than the implicit distinction from '仅返回数量不返回名单'.

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

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

The description mentions pricing details and states what metrics are returned, but does not disclose aspects like whether the result is cached, whether it requires any authentication, or any limitations on region granularity. With openWorldHint=true, the behavior is not fully transparent.

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 the main purpose in the first sentence, followed by metric details, exclusions, and examples. The pricing info is appended unnecessarily but not harmful. It is front-loaded and 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?

Given the tool's medium complexity, the description covers the purpose, metrics, and examples. The output schema exists, so return details are handled elsewhere. However, it lacks information on edge cases like empty results or validation of region/chain names, but it is adequate for a count query.

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?

All parameters have descriptions in the schema, and the description provides example values. However, it does not add the exact format or normalization rules for region names (e.g., '北京市海淀区' vs '海淀区') or chain names, which could be ambiguous. It adds minimal value beyond the schema.

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 it queries the count of discredited companies for a specific region and industry chain, and lists the metric types. It does not explicitly distinguish from the sibling 'chain_discredited_company_list' tool, but the tool name and 'count' semantics make the distinction implicit.

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 question phrasings and states what is not included, but does not explicitly say when to use this vs. the list variant or other similar tools. It lacks explicit conditions for use, though the examples help infer usage.

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

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

Annotations include openWorldHint=true, and the description adds the important detail that it returns merged text for multiple indicator types (总量/生产型/销售型/依赖型). However, no additional behavioral constraints (e.g., exact return structure, auth, rate limits) are disclosed beyond that. The description is consistent with the annotations, no contradiction.

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 main purpose, followed by exclusions and examples. The pricing information is embedded but that is extra metadata. The examples are useful but slightly verbose; still, overall it's efficient.

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 tool that returns merged text for multiple indicator types, the description covers the main use cases, exclusions, and provides examples. The output schema likely details the return structure, so the description need not explain that. It is sufficiently complete for an agent to select and invoke the tool correctly.

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?

The input schema already describes all parameters with 100% coverage. The description repeats the region and chain_name parameters but adds nothing beyond what the schema provides (e.g., no syntax for format like '全国' or combined regions). It does not compensate for any gaps because there are 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 it queries company lists with software copyrights based on region and industry chain, and lists specific indicators/types. It distinguishes from siblings by explicitly naming the copyright filter and excluding other categories, though it could better differentiate from the *_num variant (chain_have_copyright_company_num) which returns only counts.

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 includes '不包含：其他企业分类的统计；仅返回数量不返回名单' which explicitly states what the tool does not do, and provides typical question examples to illustrate usage. It implies when to use this tool (when needing the list, not just counts) but doesn't explicitly name alternatives like chain_have_copyright_company_num.

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

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

With only openWorldHint provided, the description carries the transparency burden and does disclose output aggregation behavior and what is excluded. It adds useful scope context beyond annotations, such as merging total/production/sales/dependent counts and not returning other classifications or company lists.

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 well-structured with a clear first-sentence purpose, followed by included metrics, exclusions, examples, and pricing. It is somewhat wordy but each section earns its place and supports tool selection.

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, and the description sufficiently covers invocation semantics, region/chain/year usage, returned metric categories, and exclusions. Minor ambiguity remains around the exact '合并返回...文本' format, but selection and invocation are well supported.

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 minor context like region granularity (country/province/city/district) and typical phrasings, but does not substantially extend the parameter semantics already present in the schema.

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 this tool queries the count of enterprises with software copyrights by region and industry chain, specifying the aggregated return types (total/production/sales/dependent). The explicit exclusion of '企业名单明细' distinguishes it from the sibling list tool chain_have_copyright_company_list.

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?

Typical question formats and the '不包含' exclusions give clear usage context, indicating this is for counts rather than detailed lists. It does not explicitly name the alternative list tool, but the sibling presence and exclusion make the intended use evident.

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

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

With only an openWorldHint annotation, the description carries most behavioral weight. It discloses that the result merges total/production/sales/other text, and explicitly excludes count-only returns and other classification statistics. It does not discuss pagination/defaults, but the query/list behavior is clearly conveyed.

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 core intent is front-loaded and examples are useful, but the '涉及指标/类型' section repeats the same no-patent-list types nearly verbatim from the opening parenthesis, adding redundancy and making the description longer than necessary.

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?

For a 3-parameter list query with an output schema, the description is complete enough: it includes required scope, excluded cases, and typical examples. A direct mention of the numeric sibling tool would make it slightly more complete, but it is already actionable.

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?

The schema covers all parameters, and the description adds useful semantics by specifying region granularity: country, province, city, and district. Concrete examples further clarify chain_name and year usage beyond the schema examples.

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 a specific verb-plus-resource: querying a list of companies without patents based on region and industry chain. It clearly separates this from the sibling 'num' tools and from 'have_patent' 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?

It defines when the tool is appropriate: specific region + chain name, with three typical user-phrasings. The '不包含' clause clarifies this tool is not for count-only output or other enterprise categories, though it does not explicitly name the alternative count tool.

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

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

Beyond the openWorldHint annotation, the description discloses the return semantics: the result is a merged text return containing total/production/sales/dependency counts. It also states what is not included. It does not detail edge cases or the exact response structure, but the output schema supplies that minimal gap.

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 well organized and front-loaded: the purpose appears first, followed by metric types, exclusions, and typical questions. The pricing detail is extra but harmless; overall the text is concise and scannable.

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?

For a simple count/aggregation tool with two required parameters, the description is sufficiently complete: it defines the metrics, the input scope, the exclusions, and provides example utterances. The only real omission is an explicit pointer toward chain_have_no_patent_company_list when the user actually wants raw company-level data.

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?

The input schema already fully documents all parameters with 100% coverage. The description reinforces them through realistic region/chain/year examples, but adds little beyond what the schema already provides, so a baseline score of 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?

The description clearly states the exact function (querying the count of companies with no patents by region and industry chain) and distinguishes itself from list-like siblings by clarifying it returns only merged counts for total/production/sales/dependency types and excludes company rosters.

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 explicit limits ('不包含：其他企业分类的统计；企业名单明细') and practical example questions. It does not explicitly name the list counterpart tool, but the exclusion phrase strongly implies that a separate list tool should be used when enterprise details are needed.

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

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

The description adds some behavioral context by stating that the response merges text for total/production/sales/dependent types, which is beyond the schema. It also notes the exclusion of count-only returns. However, it does not mention pagination, authentication, or other behavioral traits. With only openWorldHint annotation, the description carries some burden, but it does not fully disclose all relevant behaviors.

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 well-structured: it opens with the core purpose, then lists indicator types, exclusions, and typical queries. It is slightly verbose due to the inclusion of pricing JSON, which is not strictly needed for tool usage. However, the main content is concise and front-loaded, making it effective without excessive length.

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 that the tool has an output schema, the description doesn't need to explain return values. It covers the key aspects: inputs (region, chain), what types of lists are returned, exclusions, and typical uses. It does not mention any limitations like regional granularity (though that's in the first line) or prerequisites, but for a list tool with an output schema, it is sufficiently complete. The many sibling tools are not explicitly referenced, but the exclusions help narrow down 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?

The input schema already provides descriptions for all three parameters with examples (coverage 100%), so the schema does most of the work. The description adds value by explaining that the output merges multiple sublists (total/production/sales/dependent) and clarifying what is not included, which gives context for how the parameters influence results. This goes beyond the schema, so a 4 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?

The description clearly states the tool's purpose: it queries the list of enterprises with patents based on region and industry chain name. It explicitly lists the types of lists returned (total, production, sales, dependent) and differentiates from sibling tools by asserting it returns a list, not just a count, and does not include other classifications. This distinguishes it from chain_have_patent_company_num and other similar 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 provides typical query examples and explicitly states what the tool does NOT include (other classifications and count-only results). This gives clear boundaries for when to use this tool versus count-only or other classification tools, though it does not name sibling tools directly. The exclusions imply alternatives, but without explicit naming it is not a full 5.

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

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

The description discloses key behavioral traits: the merged text-style return across four metric dimensions ('合并返回总量/生产型/销售型/依赖型文本') and the exclusion of list details and other classifications. The pricing disclosure (100 credits per run) is a useful operational transparency bonus. Since the openWorldHint annotation carries little behavioral content, the description rightfully bears the disclosure burden, and it does so adequately, though it could add edge-case behavior (e.g., empty results, year handling).

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 tightly structured in four scannable sections: core purpose sentence, included metrics list, exclusions, and typical questions — each earning its place. The metric listing is slightly redundant with the parenthetical '（合并返回...文本）' note, but the examples and pricing block justify the overall length. It is information-dense without being bloated for a tool with this many sibling variants.

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?

For a 3-parameter tool with a high sibling count (chain_*/park_* company count/list variants), the description covers the essential ground: query dimensions (region, chain, year), output dimensions (four merged metrics), exclusions, and realistic example phrasings for NL-to-parameter mapping. The presence of an output schema means return-format details are justifiably omitted. Remaining gaps (e.g., terminology explanation of '依赖型' or multi-year behavior) are minor given the well-established sibling pattern.

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% — all three parameters (year, region, chain_name) have clear Chinese descriptions with concrete examples, setting the baseline at 3. The description's example questions do enrich region granularity understanding (全国/成都/海淀区 mapping to country/province/city levels) and show year+chain+region combination patterns, but this is confirmatory rather than additive given the schema already documents each parameter well. The schema carries the weight here.

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 pairs a specific verb (查询/query) with a well-scoped resource: count of patent-owning enterprises filtered by region (country/province/city/district) and industrial chain. It explicitly enumerates the four returned metrics (total/production/sales/dependent) and differentiates from sibling tools by stating what's excluded ('不包含：其他企业分类的统计；企业名单明细'), which directly separates it from the list-family and other classification variants.

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 'Included metrics' and 'Not included' sections clearly bound the tool's scope, and the three 'typical questions' give concrete usage contexts (e.g., '2024年全国集成电路拥有专利的企业有多少' → year/region/chain mapping). It does not name explicit alternative tool IDs like chain_company_num or chain_have_no_patent_company_num, but the exclusions and examples make it clear when this tool applies versus when another patent-status or list variant would be appropriate.

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

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

Beyond the openWorldHint annotation, the description discloses that the result is a merged text combining total/production/sales/dependency types, and that it returns a list (not just a count). It also states exclusions, which helps set expectations. No contradictions with annotations.

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 moderately long but well-structured with clear sections (scope, included types, exclusions, example questions). The pricing information is included in the same block, which is extraneous but not harmful. Overall, it is efficient and front-loaded with the core purpose.

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 output schema exists (though not shown), the description does not need to explain the return format. It explains what data types are merged and that the result is a list. The typical queries cover different region granularities, making the scope clear. It is complete enough for an agent to decide and invoke the tool correctly.

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?

The input schema already provides descriptions for all three parameters (100% coverage). The description adds value by giving concrete examples for region and chain_name, and by indicating the year field is optional. This supplements the schema without redundancy.

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 it queries high-tech enterprise lists based on region and industry chain name, and explicitly lists the types of lists it returns (total/production/sales/dependency). The name and description distinguish it from sibling tools like chain_high_tech_company_num (which returns counts only) and other chain_*_company_list variants.

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 example queries (national-level, city-level, district-level) and clarifies what is included and excluded (e.g., does not return only counts, does not cover other enterprise classifications). It implicitly guides when to use this tool over the _num variants, though it does not explicitly name alternatives.

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

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

The description indicates a query operation, implying read-only behavior, but the annotation openWorldHint=true suggests possible side effects. Since the description does not address this ambiguity or provide additional behavioral context beyond the annotation, transparency is moderate.

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 with sections for the main action, included metrics, exclusions, and typical queries. It avoids unnecessary verbosity while conveying all key information.

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?

It explains what the tool returns (total count plus breakdown by type) and what it excludes, covering the main use case. However, it does not specify the exact output format (e.g., JSON structure), which could be clarified, but this is not critical for a count-based tool.

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?

All three parameters (year, region, chain_name) are described with examples and allowed scopes (e.g., region can be country/province/city/district). The descriptions fully cover the schema, and the typical queries reinforce the meaning of each parameter.

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?

Clearly states the tool queries the count of high-tech companies in a specific region and industry chain, and lists the types of counts returned (total, production, sales, dependency). The verb '查询' and resource '高新技术企业数量' are specific, and it distinguishes from list tools by excluding enterprise lists.

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?

Provides typical queries and explicitly excludes other company classifications and lists, guiding the agent to use alternative tools for those cases. However, it does not explicitly contrast with the many other 'num' sibling tools (e.g., chain_specialized_company_num), though the 'high-tech' specificity is clear.

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

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

Annotations only provide openWorldHint, so the description carries the behavior burden. It adds meaningful details: merged return text (total/production/sales/dependent), two-year time window, and the explicit exclusion of count-only results. No contradiction with the openWorldHint annotation is present.

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 compact and sectioned into scope, metric types, exclusions, and examples. There is some repetition of '近两年有对外投资的企业列表', but the structure makes it scannable and each section contributes relevant operational context.

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?

For a list tool with an output schema and 100% parameter coverage, the description is sufficient: it gives required dimensions, examples, exclusions, and typical queries. It could be improved by explicitly relating itself to sibling count/invested-list tools, but this is not a major gap.

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?

The schema already describes all three parameters, and the description adds value with region granularity (国家/省份/城市/区县), concrete chain examples, and typical questions for region/chain/year. The relationship between the year parameter and '近两年' is implicit rather than fully explicit, but inferable from examples.

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 a specific query: companies with outward investment in the last two years for a given region and industry chain. It also enumerates the returned sub-lists (total/production/sales/dependent) and provides typical questions, distinguishing it from general chain_company_list and chain_invest_company_num.

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 '不包含' section clarifies exclusions (other enterprise classifications and count-only results), and the typical question examples illustrate when the list tool is appropriate. It does not explicitly name alternatives such as chain_invest_company_num, but the list-vs-count distinction is clear from context.

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

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

With only openWorldHint annotation, the description carries the behavioral burden and adds meaningful context: the two-year time window, merged text return of four metric types, and exclusions. It does not mention read-only nature, but the query semantics and output schema cover the expected behavior adequately.

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 well-structured with a main sentence, metric breakdown, exclusions, and examples. The metric list slightly overlaps the first sentence but each section contributes useful disambiguation, so it remains efficient and scannable without being bloated.

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 description covers purpose, parameter examples, return content, exclusions, and typical usage. An output schema exists, so return values need no further explanation. Minor gaps include the default behavior when 'year' is omitted and handling of zero-results, but these are not critical for a count query tool.

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%, so the baseline is 3. The description adds value beyond the schema by clarifying region granularity (country/province/city/district) and providing concrete examples for chain_name and year (e.g., 集成电路, 新能源, 2024), which reduces ambiguity for the agent.

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 counts companies with outward investment in the past two years, filtered by region and industry chain. It explicitly lists the returned metrics (total/production/sales/dependent) and excludes other classifications and company lists, distinguishing it from sibling chain_*_num and chain_invest_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 provides typical user questions and an explicit 'not included' section (other classifications, company lists), which helps the agent decide when this tool is appropriate. However, it does not directly name alternative tools like chain_invest_company_list for detail retrieval, relying on the exclusion statement to imply the distinction.

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

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

Beyond the single openWorldHint annotation, the description discloses the query's scope (companies with external financing in the last two years), the merged output composition (total/production/sales/dependent categories), and what is not included. It does not mention pagination, rate limits, or auth, but the 'query' framing and list-return scope make the behavior reasonably transparent.

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 main purpose is front-loaded, and the structure—scope, included indicators, exclusions, and example queries—is easy to scan. The '涉及指标/类型' section repeats the same criterion across four category variants, adding slight redundancy, but the overall length is still reasonable.

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 description is self-sufficient for tool selection and invocation: it defines the scope, output composition, explicit exclusions, and concrete example queries. Since an output schema exists, detailed return-field documentation is unnecessary, and the description compensates well for the minimal annotation set.

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% and parameter descriptions already include examples, but the description adds meaning by defining region levels (country/province/city/district), clarifying chain_name as an industry-chain/node name, and explaining the core 'external financing in the last two years' filter. This goes beyond the bare schema.

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 queries a list of companies with external financing in the last two years by specific region and industry chain. It also distinguishes this list tool from count-only siblings by explicitly saying it returns lists and does not return only counts.

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?

It provides clear usage context: region granularity (country/province/city/district), chain name, and typical user questions for scenarios like national, city, and district queries. It states exclusions—other enterprise classifications and count-only outputs—but does not explicitly name alternative sibling tools such as chain_invested_company_num.

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

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

The description mentions that it returns aggregated text (总量/生产型/销售型/依赖型) and explicitly states what is not included (other categories, list details). With openWorldHint=true, the agent knows results may vary, but the description does not elaborate on limitations like data freshness or exact definition of '近两年', which is a gap.

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 structured with sections for the query scope, included/excluded metrics, and examples, making it easy to scan. The pricing info is extra but not overly verbose; it doesn't detract from readability.

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?

For a count tool with an output schema and clear parameters, the description sufficiently explains the aggregation logic and examples. It could benefit from noting how the output is formatted (e.g., raw JSON vs. text), but the output schema likely covers that, and the tool is relatively simple.

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?

The schema covers all three parameters with descriptions, and the description adds context on how region and chain_name are used (e.g., hierarchical region names like '北京市海淀区'). However, it doesn't explain the 'year' parameter's role beyond being optional, and the coverage is high, so 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?

The description clearly states the tool queries the count of companies with external financing in the last two years, filtered by region and industry chain, and returns aggregated totals split by type. It distinguishes itself from siblings by specifying 'invested' (companies receiving investment) and the aggregation format, though it doesn't explicitly name alternatives.

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 question examples that clarify when to use this tool, such as querying counts of companies with external financing by region and chain. It does not explicitly state when not to use it, but the examples and scope (aggregated counts, excluding lists) imply its use case.

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

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

Because the annotations only supply openWorldHint and no read-only/destructive hints, the description bears responsibility for behavioral disclosure. It discloses that results are merged text for total/production/sales/dependency types, that it is limited to a two-year window, and that count-only output is not returned. This adds meaningful behavioral context beyond the structured annotations.

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 well-structured: it states the purpose, lists included metrics, states exclusions, and provides query examples. It is reasonably front-loaded and scannable. However, it contains some redundancy in the indicator list and includes the pricing block, which is operational metadata rather than semantic guidance, preventing a full 5.

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 description provides enough context to select this tool: it defines the time window, the region/chain parameters, the list-based return, and the major exclusions. Given that an output schema exists and the input schema is fully described, the description need not detail return fields. It is adequate for a moderately simple list tool among many siblings.

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?

The input schema already provides 100% coverage with useful descriptions for region, chain_name, and year. The description reinforces these via examples and the geographic granularity, but it adds little beyond what the schema already tells the agent. Therefore, without an annotation for parameter semantics, only the schema-informed baseline can be stated.

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 action: with a specific region and industry chain input, return the list of companies that issued tenders in the past two years. It also explicitly enumerates the sub-types it covers (total, production, sales, dependency) and what it excludes (count-only results and other classifications), which clearly distinguishes it from sibling count/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 usage context through parameter and example-based typical questions (e.g., '2024年全国集成电路近两年发起过招标的企业名单'). It also includes '不包含' exclusions that help the agent avoid inappropriate uses. However, it does not explicitly name sibling alternatives such as chain_issued_tender_company_num or chain_participated_tender_company_list, so it falls one step short of fully explicit when-to-use vs. alternative guidance.

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

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

With only openWorldHint among its annotations, the description carries significant transparency burden and delivers: it discloses that results are always constrained to a two-year window, that the return merges four metric categories (总量/生产型/销售型/依赖型), and what metric types are not included. It doesn't delve into the implications of openWorldHint on data coverage, but the provided behavioral insight is valuable and doesn't contradict the annotation.

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 earns its space with a clear visual hierarchy: a one-sentence definition, a compact metric list, an exclusion line, typical questions, and pricing metadata. The pricing JSON is somewhat verbose for an unstructured description field, but it's clearly delimited and the entire package remains scannable with several meaningful sections.

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?

For a tool with only 3 parameters, an existing output schema, and 100% schema parameter coverage, the description covers use cases, exclusions, examples, and scenarios comprehensively. Minor gaps remain, such as how the optional `year` parameter interacts with the fixed 'past two years' window, and a clearer note on the openWorldHint implications would further strengthen it, but overall it's quite complete.

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 at 100% with rich examples for every parameter (e.g., 「全国」「北京市海淀区」for region, 「集成电路」for chain_name). The description adds realistic combinations through the typical questions, but the core semantics of each parameter are already well-established by the schema examples and descriptions. It provides modest incremental value at best.

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 uses a specific verb+object structure (近两年发起过招标的企业数量查询) and clearly defines the geographic scope (国家，省份，城市，区县), time window (近两年), and aggregation basis (具体产业链名称). It unambiguously communicates what the tool does while disambiguating from sibling list tools via the explicit exclusion (不包含...企业名单明细) and the fact that it emphasizes count-only results.

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 clear exclusions (不包含：其他企业分类的统计；企业名单明细) and three realistic example queries (典型问法) that show typical invocation patterns from different angles. However, it never explicitly points to a sibling like chain_issued_tender_company_list as the alternative when name-level detail is needed, leaving the agent to infer from naming conventions.

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

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

The only annotation is openWorldHint, so the description must carry the behavioral burden. It discloses what the tool returns (a merged text of total/production/sales/dependent types) and what it excludes, but it lacks information on data source, freshness, or behavior when no matches are found. This is only partial transparency.

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 moderately concise and front-loaded with the core purpose. It includes useful sections for indicators, exclusions, and examples. The pricing line is somewhat peripheral but not distracting. Overall, it is well-organized and efficient.

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 presence of an output schema and numerous sibling tools, the description provides adequate context: it clarifies scope, gives usage examples, and states exclusions. It does not explicitly mention the count-only alternative, but that is a minor gap considering the robust schema and sibling naming conventions.

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%, so baseline is 3. The description adds semantic value by clarifying that region can be country/province/city/district granularity and provides concrete examples in typical questions. This goes slightly beyond the schema's simple examples, earning a 4.

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 it queries listed companies by specific region (country/province/city/district) and industry chain name, returning a merged textual result with totals and category breakdowns. It differentiates from sibling count tools by explicitly stating it returns lists, not just counts, though it doesn't name chain_listed_company_num directly.

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?

Typical user questions demonstrate when to use the tool (e.g., '2024年全国集成电路上市企业名单'). The exclusions ('不包含：其他企业分类的统计；仅返回数量不返回名单') make it clear when not to use it, implicitly steering count-only requests to the num sibling. However, it stops short of explicitly naming an alternative tool.

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

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

The annotation openWorldHint is present, and the description does not contradict it. It adds behavioral detail by stating it returns a merged text of total/production/sales/dependent counts, but does not discuss data freshness, limitations, or side effects. With the annotation present, this is adequate but not extensive.

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 a single, compact paragraph with clear sections for included types, exclusions, and examples. It is front-loaded with purpose and efficiently conveys the tool's scope. The pricing line is extraneous but does not detract from the core description.

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 an output schema exists and annotations are minimal, the description adequately covers purpose, usage examples, and exclusions. It states the return format (merged text of counts) and typical questions, making it complete for a count tool. It does not specify region hierarchy constraints, but that is implied by schema and examples.

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 year, region, and chain_name. The description provides example phrasings that map to parameters, but does not add additional semantic context beyond the schema. Baseline of 3 is appropriate since the schema already documents parameters effectively.

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 queries the count of listed companies based on region and industry chain, specifying the aggregated subtypes (total, production, sales, dependent). It distinguishes from list tools by explicitly excluding '企业名单明细' and using '数量' in the name, though it doesn't directly contrast with other count tools like chain_company_num.

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?

Typical questions (e.g., '2024年全国集成电路上市企业有多少') provide usage context, and the '不包含' section clarifies exclusions. However, it does not explicitly mention when to use this vs alternatives like chain_listed_company_list or chain_company_num, so guidance is implied rather than explicit.

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

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

Annotations are minimal (only openWorldHint=true), so the description carries the full burden of disclosing behavior. It mentions that the result is a merged text (list of types) and excludes other categories, providing some transparency about output structure. It does not explicitly state whether the operation is read-only, has side effects, or requires permissions, but given the nature of a query tool and the open world hint, the described behavior is consistent and adequate though not rich.

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: it states the core purpose first, lists included types, then exclusions, and ends with typical queries. The inclusion of pricing info is extra but not verbose. It front-loads the key information and avoids redundancy. Each sentence adds value, and the examples are helpful for quick comprehension.

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 has only 3 parameters, an output schema (as indicated by context), and is a straightforward list query, the description is sufficiently complete. It explains what is returned (merged text of lists), what is excluded, and provides concrete examples. It does not cover pagination or ordering, but for this tool that is likely not critical. The description adequately prepares the user to invoke the tool correctly.

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 descriptive text for each parameter (year, region, chain_name). The description adds value by providing typical query phrasing that demonstrates parameter usage (e.g., '成都市新能源产业链当年新增的企业列表'), which clarifies how to combine region and chain_name. While the schema already documents parameters, the examples and the statement about merging types (total/production/sales/dependent) enhance understanding of expected inputs.

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 queries a list of newly added enterprises for a specific region (country/province/city/district) and industry chain name, returning merged text for total/production/sales/dependent types. It distinguishes from sibling count tools (like chain_new_start_company_num) by explicitly noting it returns lists, not just counts. The typical query examples reinforce the precise action.

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 examples (e.g., '2024年全国集成电路当年新增的企业名单') that illustrate how to combine region, chain_name, and year. It also explicitly states what is not included (other categories, count-only returns), which implies when to use this tool vs alternatives. However, it does not explicitly name alternative tools (like chain_new_start_company_num) or provide 'when-not' guidance beyond these exclusions, so it is clear but not fully explicit.

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

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

Annotations provide openWorldHint: true, but the description does not contradict it. The description explains the return format (text combining totals and types) and excludes certain data, which adds context beyond the annotation. However, it does not disclose other behaviors like pagination or potential delays, and with only one annotation, the description could carry more weight. The absence of a contradiction allows a neutral score.

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 about three sentences and a list of examples. It is front-loaded with the core purpose and includes a pricing object which is extraneous but not harmful. The structure is clear, but the pricing information could be omitted for better focus, though it is not a significant detraction.

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 that the tool has an output schema (has_output_schema: true) and the description references a merged text output, the description is largely sufficient. However, the tool is part of a large family of chain_* tools, and the boundary between 'new_start' and other indicators (e.g., 'year5' or 'a_taxpayer') could be clearer. The description does not explicitly state that this tool only counts new starts, but the name does. Overall, adequate but not exhaustive.

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?

The schema descriptions for the three parameters are clear and self-explanatory (e.g., 'region' as area name, 'chain_name' as industry chain name). The description adds value by emphasizing that the query is for 'new start' companies and the year is optional, but it does not provide additional semantic details beyond the schema's 100% coverage. Baseline 3 is appropriate as the schema does the heavy lifting.

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: to query the number of newly started companies for a specific region and industry chain, with a breakdown by type. It differentiates from siblings by emphasizing 'new start' and the region/chain context, and notes it excludes company lists and other classifications. However, it does not explicitly name a sibling, so it slightly misses the full distinctiveness criterion.

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 question examples to illustrate when to use the tool, such as '2024年全国集成电路当年新增的企业有多少'. It also indicates what is not included (other classifications, company lists), but does not explicitly say when not to use it or suggest alternatives, which would be a score of 5. The exclusions help the agent avoid misusing it.

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

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

The description goes beyond annotations by disclosing that it returns combined text for four list types, fixes the time scope to two years, and explicitly excludes other categories and count-only results. It doesn't mention things like pagination/rate limits, but relevant behavioral boundaries are conveyed clearly.

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 well-structured and front-loaded: purpose, included metrics, exclusions, and examples. It contains some redundancy in enumerating the four list types twice, but remains efficient and readable.

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 output schema exists and the parameter schema is fully described, the overall description is sufficiently complete for selecting and invoking the tool. The main remainder is clarity around how 'year' relates to the two-year window, and no explicit pointer to the count-only sibling tool.

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?

The schema already documents all three parameters with examples. The description adds useful context by specifying accepted region levels (country, province, city, district) and giving concrete values like '全国', '成都', and '北京市海淀区'. The interaction between 'year' and the '近两年' filter remains somewhat ambiguous.

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 this tool lists companies that participated in tenders in the last two years, filtered by specific region and chain name. It explicitly mentions returning merged text for total/production/sales/dependent types, and the name plus content distinguishes it from related count-only or other tender-status 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?

Typical question examples clearly illustrate when to use the tool, and the '不包含' section clarifies what is excluded. However, it does not explicitly name alternatives like the count-only 'chain_participated_tender_company_num' or related 'won_tender'/'issued_tender' list tools.

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

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

The description discloses that the tool returns a merged total and breakdowns by production/sales/dependent types, and states what it excludes. It does not mention any side effects, but as a query tool this is implicitly read-only. The annotation openWorldHint does not contradict.

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 well-structured with separate lines for purpose, metrics, exclusions, and examples. It is informative without being overly verbose, efficiently covering necessary details.

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 description provides comprehensive context: what the tool does, what it returns, what it excludes, and typical usage examples. It is sufficient for an agent to understand the tool's scope and output.

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?

All three parameters (year, region, chain_name) have clear descriptions with examples in the input schema, and the tool description explains how they are used in the query, providing complete semantic coverage.

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 function: it queries the number of companies that participated in bidding in the last two years based on region and industry chain. It explicitly lists the metrics (total, production, sales, dependent) and excludes list details, making its purpose unambiguous.

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 context for when to use the tool by indicating it returns counts rather than lists, and gives typical questions. However, it does not explicitly contrast with sibling list tools, though the naming convention ('_num') implies the distinction.

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

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

The description adds detail that the response is a merged text of total/production/sales/dependent types, which is beyond the openWorldHint annotation. It does not disclose pagination, authentication, or rate limits, but given the minimal annotations and simple list-query nature, it is adequate but not extensive.

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 well-structured with a clear main purpose, a list of included types, exclusions, and typical queries. It front-loads the action and resource, and every sentence serves a purpose. Slight redundancy in listing the types twice, but overall efficient.

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 existence of an output schema and the moderate complexity, the description adequately covers the tool's purpose, inputs, and typical usage. It does not explain the exact output structure, but that is provided by the output schema. It could be improved by explicitly naming the count-only counterpart, but it is complete enough for an agent.

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 descriptions cover all three parameters, and the description adds value by specifying region granularity (country/province/city/district), chain name examples, and marking year as optional. This goes beyond the schema alone, justifying a score above the baseline.

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 queries specialized and innovative enterprise lists based on region and industry chain, explicitly listing the merged return types (total/production/sales/dependent). It distinguishes from the count-only sibling tool (chain_specialized_company_num) by noting it returns lists, not just quantities, and from other chain_list tools by specifying the specialized category.

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?

Provides typical query examples and explicitly excludes other enterprise classifications and quantity-only returns, guiding appropriate use. However, it does not directly mention the alternative count tool (chain_specialized_company_num) by name, though the exclusion implies it. This is clear context but could be more explicit.

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

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

With only openWorldHint in annotations, the description carries the transparency burden. It discloses the merged return format (total/production/sales/dependent type text), the scope constraints (specific region granularity and chain name), and what is excluded. This adds meaningful behavioral context beyond the minimal annotations. There is no contradiction with openWorldHint since the tool accepts open-ended strings for region/chain.

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 well-structured with clear sections: main capability, indicator types, exclusions, and typical questions. The example questions are highly valuable for an agent to pattern-match. Minor redundancy exists where the '涉及指标/类型' section partially repeats the return format already stated in the first sentence, but overall it remains compact and focused.

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 has an output schema (so return values need not be described), 100% schema coverage, and a moderate complexity (single count query with type breakdown), the description covers the purpose, return format, exclusions, and usage examples. The pricing block adds operational context. This is reasonably complete for a count-type tool, slightly shy of exceptional due to not addressing error conditions or edge cases.

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 per the rubric. All three parameters (year, region, chain_name) are documented in the schema with examples. The description adds marginal value by clarifying region granularity levels (country/province/city/district) and the merged return types, but this is incremental rather than substantial beyond what the schema already conveys.

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 identifies the verb (query/count), the resource (specialized/new enterprises - 专精特新企业), and the dual-faceted scope (specific region + industry chain name). It distinguishes itself from sibling tools like chain_specialized_company_list (list variant) and other chain_*_num count tools by specifying the exact return (merged total/production/sales/dependent type counts). The granularity of regions (country/province/city/district) is explicitly stated.

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 '不包含' (does not include) section provides explicit exclusions: other company category statistics and company list details, which implicitly directs users to the list tool (chain_specialized_company_list) and other count tools. The three typical-question examples provide concrete usage contexts. However, it does not explicitly name the alternative tools, so it stops short of the 5-level where alternatives are named directly.

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

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

The annotations only provide openWorldHint, so the description carries most of the behavioral disclosure burden. It explains that the output merges total/production/sales/dependent list text and states what is not included. No contradiction with annotations is present.

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 well-structured with a purpose line, covered types, exclusions, and typical questions, followed by pricing. There is some redundancy in repeating the four list categories, but overall it is efficient and front-loaded.

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?

For a simple 3-parameter list tool with an output schema, the description is reasonably complete: it covers usage context, input semantics, and output boundaries. It does not specify behavior when year is omitted, but the schema marks it optional and the examples are 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 the baseline is 3. The description adds useful meaning by specifying region granularity (country, province, city, district) and giving concrete examples that map to year, region, and chain_name, going beyond the schema's brief examples.

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 it queries a science-tech SME list by specific region and industry chain, and explicitly lists the four returned categories (total, production, sales, dependent). It also distinguishes itself from count-only sibling tools by stating '仅返回数量不返回名单' is not included.

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?

Typical questions such as '2024年全国集成电路科技型中小型企业名单' make the intended usage concrete. The description gives an explicit exclusion ('不包含：其他企业分类的统计；仅返回数量不返回名单'), which tells the agent not to use this tool for count-only queries, though it does not name the sibling num tool explicitly.

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

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

描述明确说明合并返回总量/生产型/销售型/依赖型文本，披露了返回内容的结构；也说明不包含其他分类统计和企业名单明细。虽然annotations只有openWorldHint=true，未包含readOnlyHint/destructiveHint，但'查询'一词暗示非破坏性操作，且描述对返回内容的说明已超出基础schema，提供了有用的行为上下文。计费信息（Pricing）也提供了成本透明度。

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?

描述结构清晰：首句说明核心功能，然后列出涉及的指标/类型和不包含范围，最后给出典型问法示例，每部分都有实际信息量。虽稍长但无冗余填充，计费信息和描述在合理范围内。

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?

工具参数少（3个）、有输出schema（has output schema: true）、schema覆盖率100%，描述已经足够完整，包含了功能、指标明细、排除范围、典型问法，还补上了计费信息。代理可以正确调用该工具而无需额外猜测，上下文完整性良好。

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描述覆盖率100%（3个参数全部有描述），但描述额外提供了参数的典型示例（如地区'全国''成都''北京市海淀区'，产业链'集成电路''新能源''人工智能'），并且解释了region和chain_name在逻辑上的关系（地区限定、产业链限定），这有助于代理构造正确的参数。因此虽未提供语法细节，但示例和场景补充提升了参数语义。

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?

描述明确说明基于地区和产业链名称查询科技型中小型企业数量，并列出合并返回的三种类型（生产型/销售型/依赖型）及典型问法，动词和资源明确，与sibling中的chain_tech_oriented_company_list（列表工具）形成明显区分，同时与chain_company_num等计数工具区分了统计口径（仅限科技型中小企业，不包含其他企业分类）。

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?

描述明确列出使用场景（具体地区+产业链名称查询数量），并通过'不包含'条目排除了统计企业名单明细和其他分类统计，让代理知道该工具不做什么。典型问法示例（2024年全国集成电路等）提供了清晰的调用场景，但未明确提及何时应使用sibling中的list工具而非本num工具，这算轻微不足。

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

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

The description discloses the time window (last two years), the merge of totals/types into text, and exclusions, but lacks details on output format, pagination, or any side effects. With only openWorldHint annotation, more behavioral context could be added, but it doesn't contradict annotations.

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 well-structured: purpose first, then included types, exclusions, and examples. It's somewhat long but each section adds value, and the typical questions make it actionable without excessive verbosity.

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 output schema exists, the description doesn't need to detail return fields. It covers key usage aspects: region/chain combination, time window, exclusions, and examples. It could mention limits or pagination, but that's likely in output schema. Overall, it provides sufficient context for most queries.

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 covers 100% of parameters with descriptions, and the description adds concrete examples (region like '全国', '成都', chain_name like '集成电路') and typical question patterns that clarify usage of region, chain_name, and optional year. This goes beyond the schema's basic definitions.

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 queries companies that won tenders in the last two years based on region and industry chain, and explicitly lists the included result types and exclusions. It differentiates from sibling tools like chain_won_tender_company_num by specifying it returns the list, not just a count, and gives typical query examples.

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 questions that illustrate when to use this tool, and explicitly notes exclusions (other categories, count-only results). However, it doesn't explicitly recommend this over similar tools like chain_participated_tender_company_list, though the context implies it for won-tender lists.

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

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

描述说明了返回的是文本形式（合并返回总量/生产型/销售型/依赖型文本），并列出涉及指标，但未披露具体行为如年份参数的具体影响（是否覆盖固定两年还是可指定）、无数据时的返回、是否需要权限等。openWorldHint标注未增强描述，且描述未补充额外行为细节，因此处于中等水平。

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?

描述包含指标列表和典型问法，信息量足但结构稍显冗长：开头和指标部分有重复，且价格信息混入描述中，分散注意力。虽然整体清晰，但并非特别精炼，故给3分。

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?

工具参数少（3个），有输出schema和openWorldHint，描述提供了典型问法、排除项和指标明细，足够指导基本用法。尽管未详细说明年份处理，但考虑到复杂度低，描述整体已较为完整，故得4分。

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对三个参数的描述覆盖100%（region、chain_name、year），描述本身未添加额外信息，如year的默认行为或格式要求。典型问法提供了一些示例，但不足以弥补对参数语义的深度解释，因此维持基线3分。

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?

描述明确说明工具用于查询近两年有中标的企业数量，基于地区和产业链，并列举了返回的指标类型（总量/生产型/销售型/依赖型）。它清晰地定义了资源和操作，且通过典型问法展示用法。但未显式区分同族的列表工具（如chain_won_tender_company_list），因此未达到5分。

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?

描述提供了典型问法示例和排除项（不包含企业名单明细），隐含了使用场景，但未明确说明何时用此工具而非列表工具或何时用其他筛选条件。缺少显式的替代方案指引，如'当需要数量时使用此工具，需要名单时使用列表工具'。故仅得3分。

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

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

The description adds meaningful behavioral context beyond the openWorldHint annotation by disclosing that results merge total/production/sales/dependent lists and that other enterprise classifications are excluded. Since the annotations do not already describe return composition or exclusions, this is valuable transparency; no contradiction exists.

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 moderately long but front-loaded with the core purpose, then organized into indicators, exclusions, and typical examples. The structure makes it skimmable, and the pricing block is additional metadata rather than redundant explanation.

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?

For a three-parameter list query with an output schema and openWorldHint annotation, the description covers the key selection criteria, return categories, exclusions, and representative questions. It is complete enough for an agent to select and invoke the tool correctly, though naming the count-only sibling explicitly would have made it stronger.

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?

The input schema already documents all three parameters with examples, so the baseline is 3. The description adds typical question patterns and mentions region granularity, but it does not significantly extend the semantics of the parameters beyond what the schema provides.

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 queries a list of companies surviving more than 5 years based on a specific region and industry chain, using the specific verb '查询' and a well-defined resource. It also differentiates itself from count-only tools by explicitly excluding '仅返回数量不返回名单', though it does not directly name sibling alternatives.

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 clear usage context with typical question examples and specifies exclusions such as other enterprise classifications and count-only results. It does not explicitly name alternative tools like chain_year5_company_num, but the negative guidance and examples make the intended use reasonably clear.

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

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

With only openWorldHint: true in annotations, the description carries most transparency weight and delivers: it discloses that results are returned as merged text across four type dimensions (总量/生产型/销售型/依赖型) and clarifies the input region granularity. It adds exclusion context not inferable from the schema. However, it doesn't detail edge behavior such as what happens when a region/chain returns zero results or how open-world data gaps are handled, though the openWorldHint annotation partially softens this for a simple count tool.

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 core content is logically organized into purpose, metrics/types, exclusions, and examples, with front-loaded intent. However, the embedded 'Pricing: {...}' block is extraneous metadata that clutters the description, and the metric list partially restates the title's 5-year concept. It earns its place but could be tightened—solid but not exemplary.

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?

For a low-complexity tool (3 params, 2 required, no enums) with 100% schema coverage and an existing output schema (so return values needn't be re-explained), the description covers the key gaps: purpose, return-type composition, exclusions, and examples. The only minor omission is guidance on ambiguity (e.g., how region names are resolved), but this is a reasonable completeness level for this tool's simplicity.

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% (all three params documented), setting a baseline of 3. The description adds value above this by elaborating the region param's granularity (国家/省份/城市/区县) and by showing through examples how chain_name and region combine (e.g., '2024年全国集成电路'). While useful, the incremental semantic depth over the schema is moderate, not extensive—hence a 4 rather than a 5.

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 a specific verb+resource: querying the count of enterprises surviving 5+ years for a specific region and industry chain, with merged returns for total/production/sales/dependent types. It explicitly lists included metrics and exclusions ('不包含：其他企业分类的统计；企业名单明细'), which differentiates it from sibling tools like chain_year5_company_list (list vs. count) and chain_company_num (without the 5-year filter). The typical-question examples further anchor its purpose.

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 usage context via typical question examples ('典型问法') covering different region granularities and chains, and specifies what is not included (other classification categories, company list details), which acts as a when-not-to-use signal. However, it never explicitly names alternative tools (e.g., chain_company_num without year5) or states the condition under which a different tool would be preferred, so it falls one step short of fully explicit alternatives.

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

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

The description adds useful scope context: it queries only already-approved subsidies and lists the returned categories. However, it does not disclose behavior beyond that, such as exact-name matching requirements, pagination behavior, or data currency. The openWorldHint annotation is present but the description does not explain what it means for results.

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 a single clear sentence front-loaded with the tool's purpose, followed by a compact pricing line. It is efficient and readable, though the pricing block is not directly relevant to behavioral description.

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?

With an output schema present and full parameter schema coverage, the description is largely complete for a simple query tool. It clearly states the query scope and returned categories. The main missing piece is explicit guidance on when to choose this tool over closely related siblings, but this is not a major gap for such a focused query.

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%: company_name, page, and limit are all described with meanings and defaults in the schema. The description adds no additional parameter-level semantics beyond what the schema already provides, so the baseline score of 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?

The description uses a specific verb ('查询') and resource ('该企业已获批的政策补贴信息'), listing concrete returned fields like project name, type, level, reward, and year. This clearly distinguishes it from sibling tools such as company_can_apply_subsidy by emphasizing '已获批' (already approved).

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 implies usage when an agent has a specific company name and needs approved subsidy information, but it does not explicitly state when to use this tool versus alternatives like company_can_apply_subsidy or company_project. No exclusions or when-not-to-use guidance is provided.

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

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

With only openWorldHint as an annotation, the description carries the transparency burden. It clearly indicates a read-style query, lists the returned information fields, and even includes pricing information. It does not fully describe edge-case behavior, but for a straightforward query tool this is reasonably transparent.

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 core description is a single, front-loaded sentence that efficiently communicates purpose and output fields. The appended Pricing JSON is somewhat non-standard placement, but it still provides useful cost information without adding significant bloat.

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?

For a simple query tool with one required parameter, full schema documentation, and an output schema present, the description is nearly complete. It explains what is returned and emphasizes the required company name. It lacks explicit alternative guidance, but the overall context 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 the schema already documents all three parameters well. The description reinforces that company_name must be explicitly provided but adds little beyond the existing parameter descriptions. 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?

The description states a specific action and resource: it queries APP information developed by a clearly specified company, including app name, category, and introduction. This is distinct from sibling tools that focus on other company-related assets, such as websites, WeChat, or general works.

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 phrase '基于明确指定的企业名称' implies the tool is appropriate when an exact company name is known, but it does not explicitly say when not to use it or mention alternatives among the many sibling tools. Usage context is implied rather than directly stated.

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

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

The description provides extensive detail about the output field set, including status flags like whether the company is revoked, abnormal, or a credit-losing party. It also discloses per-run pricing, which is beyond what annotations supply. The query semantics imply a read-only operation, and no contradiction with the openWorldHint annotation exists.

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 front-loads the primary action and then provides a long but purposeful enumeration of returned fields. While the field list is extensive, it directly informs the agent about the tool's output scope and pricing, so the length is justified rather than wasteful.

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?

For a single-parameter lookup tool with an output schema present, the description is sufficiently complete: it specifies the exact input requirement, lists the output dimensions, and notes the cost. It does not discuss error cases or exact-match behavior, but these are not critical for this simple tool.

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?

The only parameter, company_name, is already fully described in the input schema with an example and required designation. The tool description adds little about the parameter itself beyond restating that a clear company name is needed, so it does not significantly improve on the schema.

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 queries basic company information by a specified company name, and enumerates the specific information dimensions returned. This distinguishes it from sibling tools like company_data_search or search_company_candidates, which focus on broader search or candidate matching.

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 phrase '基于明确指定的企业名称' establishes the key usage context: this tool is for looking up a company when its exact name is already known. It does not explicitly name alternatives or when-not-to-use scenarios, but the implied boundary against search-oriented sibling tools is clear enough.

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

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

The annotations include openWorldHint: true, indicating results may be open-ended. The description explains return fields but doesn't discuss pagination behavior beyond schema, nor any data limitations. There's no contradiction, so the score is moderate.

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 one clear sentence plus a pricing note. It is front-loaded with the main functionality; the pricing is extra but acceptable. Slight omission of pagination details but overall efficient.

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 simplicity, the description covers the main purpose and output fields. With a high schema coverage and output schema present, the description is sufficiently complete, though it could mention pagination defaults more explicitly.

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?

The schema has 100% coverage, so parameters are well-described. The description adds context about the purpose but doesn't add new parameter semantics beyond the schema, justifying a baseline score.

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 queries a company's branches nationwide based on the company name, returning details like branch name, responsible person, setup date, and operating status. It distinguishes itself from siblings by focusing on branch queries for a specific company.

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 implies usage when branch information for a company is needed. However, it doesn't explicitly state when not to use it or mention alternatives among siblings, but the context is clear enough for typical queries.

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

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

Annotations only include openWorldHint=true, which is minimal. The description notes results include project name, type, and rewards, and mentions pagination via schema. However, it doesn't disclose what happens if the company is not found, whether results are real-time or cached, or if partial matches are returned. Given the limited annotation coverage, the description could add more.

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 in one sentence plus a pricing note. It front-loads the main purpose. However, the pricing information is structured data that could be omitted or formatted; it's not harmful but adds noise.

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 (though not shown) and 100% schema coverage, so the description doesn't need to explain return format. Still, for a query tool with multiple siblings, more context (e.g., how results differ from company_acquired_subsidy, whether subsidies are current or historical) would help. But given the schema richness, the description is adequate.

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%, so the baseline is 3. The description mentions the company_name parameter is required but doesn't add meaning beyond the schema's example. The schema already documents page and limit with defaults and max. No additional insight is provided by the description.

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 queries subsidy information for a specified company name, including project name, type, and policy rewards. It distinguishes from siblings like company_acquired_subsidy (past acquisitions) by focusing on '可申领' (can apply for). However, it doesn't explicitly contrast with siblings.

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 implies use case (query subsidies for a company) but provides no explicit guidance on when to choose this over similar tools like company_acquired_subsidy or enterprise_change_policy_fiscal_support. No exclusions or alternatives are named.

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

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

Annotations provide only openWorldHint and no readOnly/destructive hints, so the description carries the burden. It describes a query operation, implying read-only behavior, but does not explicitly state side effects, permissions, or rate limits. It does list the output fields, which partially covers transparency.

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 a single, focused sentence that clearly conveys the purpose and output fields without extraneous information. It is well-structured and easy to parse.

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 description is sufficient for a simple query tool: it states the input (company name) and the output fields. Pagination parameters (page, limit) are defined in the schema, so not repeating them in the description is acceptable. The tool's scope is fully explained.

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% for the three parameters (company_name, page, limit) with descriptive text. The description repeats the company_name parameter but adds no new semantic detail beyond the schema. Baseline of 3 is appropriate given high schema coverage.

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 function: querying qualification certificates for a specified company, and enumerates the fields returned (certificate number, type, dates, status, etc.). This is specific and distinguishes it from sibling tools like company_basic_info or company_patent.

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 no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or scenarios. While the purpose is self-evident, it lacks the explicit 'when to use' direction seen in better-calibrated examples.

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

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

Annotations only include openWorldHint, with no readOnlyHint or destructiveHint. The description uses '查询' (query) implying a read-only operation, but does not explicitly disclose safety, permissions, or pagination behavior. Without annotations, the description carries the burden; it fails to clarify if data is mutable or any access restrictions. No contradiction with annotations, but insufficient disclosure.

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 two concise sentences (plus pricing info) that front-load the purpose and examples. There is no fluff or redundancy; it is directly informative for an agent.

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 is simple with 3 parameters and an output schema exists, so return value details need not be in the description. The description covers the core functionality and examples, but omits potential nuances like sorting or handling multiple change records. Given the output schema, completeness is adequate, though slight gaps remain regarding edge cases.

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 schema already documents page, limit, and company_name. The tool description adds examples of company changes but does not enhance parameter understanding beyond what the schema provides. Baseline 3 is appropriate since schema handles the heavy lifting.

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 queries a company's change records, with dimensions like before/after change, content, and date. Examples of specific changes (legal representative, registered capital) make the purpose concrete. It is distinct from sibling tools that focus on specific change types (e.g., enterprise_change_executive_change) by covering general changes, though it doesn't explicitly name alternatives.

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 implies usage when a specific company name is known ('基于明确指定的企业名称'), but provides no explicit guidance on when to prefer this over sibling tools like enterprise_change_* or company_basic_info. No exclusions or alternatives are mentioned. The context is clear but not fully elaborated.

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

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

Annotations include openWorldHint=true, which already signals potential side effects/external dependencies. The description adds no extra transparency (e.g., rate limits, authentication, or side-effect details). It does not contradict the annotation and correctly frames the tool as a query operation, so a neutral 3 is appropriate given the annotation's presence.

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 a single sentence that directly states the purpose and key fields, followed by pricing info that is concise and non-intrusive. No redundant or irrelevant information is present, making it highly efficient and front-loaded.

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 is a straightforward query with a small parameter set and an output schema. The description mentions key returned fields and provides a clear use case. It is complete enough for an agent to understand the tool’s function without needing additional context, though it could mention pagination behavior more explicitly, but the schema covers that.

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%, with each parameter (page, limit, company_name) having clear descriptions, including an example for company_name. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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 queries chattel mortgage information for a specified enterprise, listing specific fields (registration date, status, secured claim amount, etc.). It is specific and distinguishes from sibling tools like company_equity_pledge, which focuses on equity pledges. The purpose is unambiguous.

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 implies usage (when the user needs chattel mortgage info for a company), but it does not explicitly mention when to use this tool over alternatives or provide exclusions. Given the large sibling tool list, some explicit guidance would help, but the purpose is strong enough that an agent can infer when to invoke it.

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

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

The description lists the output fields, which gives some behavioral context. The openWorldHint annotation is present, and the description doesn't contradict it. However, it doesn't disclose potential limitations like pagination behavior (though page/limit params exist), data freshness, or whether results are complete. The pricing info is included but that's not behavioral. With the annotation present, the bar is lower, and the description adds the field list, which is useful but not rich.

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 a single paragraph that front-loads the purpose and lists the output fields. It's efficient with no wasted words. The pricing info is appended, which is slightly extraneous but not harmful. It's appropriately sized for the tool's complexity.

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 (not shown in detail) and 100% schema coverage, so the description doesn't need to explain return values. However, given the tool's complexity (many output fields, pagination), the description could benefit from clarifying the pagination behavior or noting that results may be incomplete (openWorldHint). It's adequate but not complete for a tool with this many fields.

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 schema already documents all three parameters (company_name, page, limit) with descriptions. The tool description adds the list of returned fields, which helps understand what the company_name parameter will retrieve, but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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 queries competitor information for a specified company, listing the specific fields returned (project name, tags, funding round, etc.). It distinguishes from siblings by focusing on 'competing' (竞品) information, which is unique among the many company_* tools. However, it doesn't explicitly contrast with similar query tools like company_basic_info or company_financing, so it's clear but not fully differentiated.

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 implies usage: provide a company name to get competitor info. It doesn't explicitly state when to use this vs. alternatives (e.g., company_basic_info for company details, company_financing for funding). The openWorldHint annotation suggests it may return partial results, but the description doesn't clarify when this tool is preferred over others. No exclusions or alternative tool names are mentioned.

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

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

The description's '查询' implies a read-only lookup and adds pricing context (0.2 credits per run), which is useful beyond the openWorldHint annotation. However, it does not disclose rate limits, auth requirements, exact-match failure behavior, or other side-effect details.

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 main description is a single front-loaded sentence with a clear verb, prerequisite, and field list, followed by a compact pricing note. There is no filler, repetition, or unnecessary detail.

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?

For a paginated query tool with a rich output schema and 100% schema coverage, this description is largely sufficient: it names the required input, return fields, and cost. It could be more complete by explicitly addressing exact-match behavior or sibling distinctions.

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 schema already documents all three parameters. The description adds no additional input-parameter semantics; it only restates the company_name requirement and lists output fields.

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 opens with a clear verb '查询' and a specific resource: software copyright information owned by a company, with a detailed field list. This clearly distinguishes it from sibling IP tools like company_patent and company_trademark.

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 states the prerequisite '基于明确指定的企业名称', signaling that an explicit, specified company name is required. It does not explicitly name alternatives or when-not-to-use cases, so it stops 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.

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

The only annotation is openWorldHint: true, which gives minimal behavioral context. The description adds useful details like the returned fields and per-run pricing of 0.2 credits, but it does not disclose pagination behavior, possible empty results, or any read-only guarantees. Since annotations are sparse, the description carries much of the burden but only partially fulfills it.

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 one concise sentence that front-loads the core purpose, followed by a compact pricing block. There is no fluff or redundancy, and every element serves a clear communication purpose.

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?

For a simple lookup tool with one required parameter, an existing output schema, and complete parameter descriptions, the description covers the essential intent and cost. It lacks caveats such as whether the company name must be an exact legal name or whether credit ratings exist for all companies, but these are minor gaps given the tool's simplicity and schema richness.

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 parameters (page, limit, company_name) are already fully documented. The description adds no additional semantic detail beyond restating that company_name must be explicitly specified, which matches the schema. 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?

The description clearly states the tool's function: query credit rating information for a specified company, listing key return fields (主体评级、评级展望、评级机构、评级时间). This verb+resource structure is specific and distinguishes it from sibling tools that cover other company data such as violations, executives, or subsidies.

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 phrase '基于明确指定的企业名称' provides clear context that the tool requires a specific, known company name. It implies the intended use case without explicitly naming alternative tools or stating when not to use it, so it falls at 4 rather than 5.

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

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

The description includes behavioral details beyond the openWorldHint annotation: it mentions that results are based on business-related data items, and includes pricing information (credits per returned row). It does not mention side effects or permissions, but as a search tool, its non-destructive nature is implied. The inclusion of pricing and return type adds transparency, though it does not cover all potential behaviors (e.g., rate limits).

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 well-structured and concise given the tool's complexity. It follows a logical flow: purpose, filter categories, results, exclusions, and examples, followed by pricing. There is no redundant information, and each sentence contributes to understanding the tool's usage and scope. The length is justified by the need to explain multi-part filters and provide disambiguation.

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 description is comprehensive for a search tool. It covers the primary purpose, filter types, result type, exclusions, and typical usage examples. Since an output schema exists, it does not need to explain return values. The inclusion of pricing and the explicit mention of alternatives (gov_data_enterprise_scale/change) makes it self-contained for an agent to decide when to invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.