CN Evidence

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

With no annotations, the description carries the full burden and does so well: it discloses first-page-only retrieval, a 5-row cap, no pagination input, a per-call price of 0.011000 USDC, and that nonempty row semantics were not independently verified. It omits auth/permission requirements, but the limitation disclosures are unusually concrete.

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 purpose is front-loaded in the first Chinese sentence, but the body is a repetitive hedge: 'No independent entity identity, freshness, completeness...' is restated by 'No completeness or safety guarantee', and 'first page only, at most 5 rows, no pagination input' is restated by 'Additional pages require separate requests.' Several sentences do not earn their place.

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 the safety/limitation profile and data source, which is the critical context for a no-annotation, no-output-schema tool. It still leaves the shape of returned rows and the full argument contract dependent on an external schema call, so an agent lacks enough to call it confidently in one step.

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 0% and the single 'arguments' property is an opaque nested object with additionalProperties true. The description partially compensates by naming the company_id field and pointing to get_cn_data_tool_schema for the full argument contract, but it does not enumerate required fields itself.

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 opening states a specific verb and resource: query administrative penalty decisions, publication dates and penalty content. It is clearly a distinct data resource, though it does not explicitly distinguish itself from similarly-scoped siblings such as cn_data_v3_tax_punishment_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?

It gives operational prerequisites ('Use company_id from cn_data_v3_company_detail', 'Pass arguments matching get_cn_data_tool_schema(...)') and warns that an empty result is not a safety finding. However, it never states when to choose this tool over a related penalty or risk sibling, so alternative selection is left to inference.

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 no annotations, the description carries the full burden and delivers real behavioral context: per-call cost (0.011 USDC), pagination behavior ("Additional pages require separate requests"), and explicit limits (no independent attestation of entity identity, freshness, completeness, ownership, or safety). The only gap is that it doesn't describe permissions/rate limits beyond price.

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 purpose is front-loaded, but the body is a run-on sequence of mixed Chinese/English disclaimers with redundancy ("No completeness or safety guarantee" restates the earlier completeness clause). Most sentences carry information, but the structure is not economical.

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 no annotations, no output schema, and an opaque argument wrapper, the description covers the key operational facts an agent needs: cost, prerequisite call chain, pagination, and the limits of what the returned record attests. It is close to complete for this tool's complexity.

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 single parameter is an opaque free-form object with 0% schema description coverage, so the schema provides no help. The description partially compensates by naming the required record_id and its provenance, and by redirecting to get_cn_data_tool_schema("v3_app_detail") for the full argument contract, but it does not enumerate the actual argument keys.

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?

"查询单个 APP 详情" gives a specific verb+resource (single APP detail) and is distinguished from the sibling cn_data_v3_app_list, which is explicitly named as the source of record_id. It stops short of a 5 because the purpose sentence is terse and the rest of the text is disclaimer rather than further scoping.

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 states the prerequisite directly: record_id must come from cn_data_v3_app_list and "acquiring that list is a separate call," which tells the agent the correct call ordering. There is no explicit when-not-to-use statement, so it falls short of 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?

With no annotations, the description carries the full burden and does disclose real traits: cost (0.011 USDC per call), null-means-unknown semantics, no completeness/safety certification, and that a summary is not the record list. These are valuable, but they read as generic boilerplate applied uniformly and say nothing specific about this call's behavior or return shape.

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 purpose is front-loaded, but the remainder is a wall of repeated generic disclaimers ('No completeness or safety guarantee' appears twice, alongside near-duplicate caveats about certification and summary vs. record list). For a one-parameter count tool, most of the text does not earn its place.

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 no output schema and a bare input schema, the description does supply cost, the company_id source, and null/guarantee caveats. It still leaves the actual argument contract and the meaning of the returned count (per-company total? split by APP vs. mini-program?) unspecified.

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 is a single opaque 'arguments' object at 0% description coverage, so the description must compensate. It partially does by pointing to get_cn_data_tool_schema('v3_application_count') for the argument shape and by naming company_id as the expected input, but it never documents the argument inline.

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 opening sentence states a specific verb and resource: querying the count of enterprise APPs and mini-programs. It is clear on its own, though it does not distinguish itself from siblings like cn_data_v3_app_list, cn_data_v3_minapp_list, or the *_count family, leaving the agent to infer the 'count vs. list' distinction from the name.

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 gives one concrete prerequisite ('Use company_id from cn_data_v3_company_detail'), which is genuinely useful input guidance. However, it never says when to choose this tool over cn_data_v3_app_list/minapp_list or the other count siblings, and the pagination note ('Additional pages require separate requests') is odd for a 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?

With no annotations, the description carries the full burden and does well: it discloses a hard cap ('first page only, at most 5 rows; no pagination input'), cost per call (0.011 USDC), and what the data does not prove (identity, completeness, safety, current ownership). It omits the return fields and any auth requirements, keeping it short of a 5.

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?

Eight sentences with substantial redundancy: 'does not independently attest entity identity or completeness' is restated by 'No completeness or safety guarantee,' and 'Additional pages require separate requests' repeats 'first page only.' The useful facts (company_id, 5-row cap, price) are buried among repeated disclaimers, so not every sentence earns its place.

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 no output schema, no annotations, and a nested/untyped argument object, the description covers limits, cost, prerequisites, and disclaimers, but never describes the returned row structure beyond 'at most 5 rows.' An agent still lacks the field-level picture of what comes back.

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 0% and the single parameter is an opaque pass-through 'arguments' object, so the description must compensate. It names the required input ('Jinghai company_id') and points to get_cn_data_tool_schema("v3_app_list"), but defers the actual parameter shape to another tool rather than documenting it 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 names the resource ('Recorded mobile applications'), making clear this returns a company's app records, and the name plus context imply listing. It does not explicitly contrast itself with siblings like cn_data_v3_app_detail (single app) or cn_data_v3_minapp_list, so differentiation is left 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?

It states a concrete prerequisite ('Requires the Jinghai company_id from cn_data_v3_company_detail') and a usage constraint ('Additional pages require separate requests'), which tells the agent how to invoke it correctly. However, it never says when to prefer this over app_detail or minapp_list, so no explicit alternative routing.

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 no annotations, the description carries the full burden and does meaningful work: it discloses a per-call price (0.011 USDC), that one call = one company query, that additional pages require separate requests, and that nulls mean unknown. It also warns that a summary/header is not the underlying record list and that no completeness/safety certification exists. The disclaimer boilerplate is repeated but the operational facts are 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?

Purpose is front-loaded, but the body mixes Chinese and English and stacks overlapping disclaimer clauses ('No independent entity identity, freshness, completeness, ownership, compliance or safety certification' vs 'No completeness or safety guarantee'). Several sentences earn their place (cost, pagination); the duplication does not.

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 no output schema, no annotations, and an opaque free-form argument object, the description supplies most of what an agent needs: cost, page-vs-request semantics, null handling, summary-vs-records scope, and ID provenance. The remaining gap is the actual argument names, which it delegates to a companion schema tool rather than leaving undiscoverable.

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 0% and the single 'arguments' bag has additionalProperties: true, so the schema tells an agent nothing. The description partially compensates by requiring company_id and by directing the caller to get_cn_data_tool_schema("v3_bid_count") for the real argument shape, but it never enumerates or formats any parameter itself.

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 opening line gives a specific verb+resource: query a company's bidding/bid count overview (查询企业招投标数量概览). It is distinguishable from list-oriented siblings because it explicitly returns a summary/header rather than records. It stops short of naming the closest alternative (cn_data_v3_bid_header) to disambiguate when you want totals vs individual bids.

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 gives one concrete prerequisite: source the company_id from cn_data_v3_company_detail. That is useful input routing, but there is no explicit when-to-use/when-not-to-use guidance relative to the many bid-related siblings (bid_header, company_detail). Usage is inferable from the 'count overview' framing rather than 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?

With no annotations provided, the description carries the full burden and does disclose meaningful behavior: cost (0.011 USDC per single call), pagination behavior (separate requests per page), return shape (one array), and data caveats (not complete history, headers are not underlying records, no completeness/safety guarantee). These are substantive for a header/statistics tool, though a few caveats are repeated.

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?

Purpose is front-loaded, but the text is a run-on list of repeated disclaimers ('not guaranteed complete history' and 'No completeness or safety guarantee' say substantially the same thing), and it mixes Chinese and English within one block, adding friction without adding 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?

For a tool with no annotations, no output schema, and a generic arguments object, the description covers the essentials an agent needs: purpose, cost, pagination, input source, and data-reliability caveats. It could be more complete on the actual argument fields, but overall it 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?

The schema is a single opaque 'arguments' object at 0% description coverage, so the schema itself explains nothing. The description partially compensates by pointing to get_cn_data_tool_schema("v3_bid_header") for the argument contract and identifying company_id as the key input, but it does not enumerate or explain the actual parameter 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 opening sentence states a specific verb+resource: querying enterprise bidding (招投标) publication-channel statistics. It is clear what the tool returns, though it does not explicitly differentiate itself from the sibling cn_data_v3_bid_count, so the agent must infer the distinction between a header/statistics view and a raw count.

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 supplies the input source ('Use company_id from cn_data_v3_company_detail') and notes that 'Additional pages require separate requests', which are useful operational cues. However, it gives no explicit when-to-use or when-not-to-use guidance relative to alternatives like cn_data_v3_bid_count, leaving usage implied.

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 no annotations, the description carries the full burden and does well: it discloses the provider first-page-only cap (≤5 rows), that no pagination input exists, that additional pages require separate requests, the per-call cost (0.011 USDC), and that it does not attest entity identity or completeness. Only a note on required permissions or return shape is missing.

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?

Front-loads the core purpose and the key constraint (first page only), but several sentences are filler or redundant – 'One selected Chinese company data tool call' carries no meaning, and the two completeness disclaimers overlap.

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 no-annotation, no-output-schema, opaque-schema tool this is fairly complete: cost, pagination limits, dependency chain, and reliability caveats are all covered. What remains missing is the concrete argument list and any differentiation from sibling list endpoints.

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 0% and the single 'arguments' object is opaque (additionalProperties: true), so the description must compensate. It names the required Jinghai company_id and defers the rest to get_cn_data_tool_schema("v3_branch_org_list"), which adds real value but stops short of enumerating the argument shape.

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?

States a specific resource (recorded branch organizations of a company) with an implicit list verb, and names the required company_id source. It does not explicitly distinguish itself from the many sibling *_list tools (key_person_list, shareholder_list, etc.), so differentiation is only partial.

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?

Gives a genuine prerequisite – the company_id must come from cn_data_v3_company_detail – which helps sequencing. However it offers no explicit when-to-use vs alternatives or when-not condition across the large sibling set, leaving selection mostly to inference.

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 no annotations, the description carries the full burden and does a fair job: it discloses per-call cost (0.011 USDC), that additional pages require separate requests, that null means unknown, that a summary/header is not the underlying record list, and it disclaims freshness/completeness/safety certification. What is missing is any auth/permission requirement or failure behavior, keeping it out of the top band.

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 purpose is front-loaded well, but the body is a run-on of disclaimers that repeat the same idea — 'no ... completeness ... or safety certification' near the start and 'No completeness or safety guarantee' at the end. The repetition costs space without adding new 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?

For a no-output-schema, no-annotation count tool, the description supplies pricing, pagination, null semantics and entity-identity caveats, which covers the operational essentials. It still never describes what the returned count(s) actually contain or how the risk categories are broken out, so an agent cannot fully predict the response.

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 0% and the single 'arguments' object is opaque (additionalProperties: true), so the description must compensate. It does point to get_cn_data_tool_schema('v3_business_risk_count') for the argument contract and names company_id as the entity key, which is meaningful, but it leaves the rest of the argument shape undocumented.

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 opening sentence ('查询经营异常、行政处罚及风险总数') gives a specific verb and resource set — it is a count/aggregate over business-abnormality, administrative-penalty and related risk data. It partially distinguishes itself from siblings like cn_data_v3_administrative_penalty and cn_data_v3_operation_exception by being a total-count rather than a record list, though it never names those siblings 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?

The only usage hint is 'Use company_id from cn_data_v3_company_detail', which tells where to source the key field but not when this tool should be chosen over the many risk-related siblings. There is no when-to-use or when-not-to-use guidance and no stated prerequisites.

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 no annotations, the description carries the full behavioral burden and does so richly: it discloses the exact cost (0.011000 USDC per call), that additional pages require separate requests, that the record id is checked exactly but company association is not independently attested, and that there is no completeness or safety guarantee. These are meaningful operational and trust caveats beyond what the schema provides.

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 purpose is front-loaded in the first sentence, but the English portion repeats disclaimers: 'No ... completeness ... certification' and 'No completeness or safety guarantee' overlap, and the cost/pagination notes are buried after lengthy boilerplate. It is information-dense but not tight.

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 no output schema and a shallow input schema, the description covers the essential call context: prerequisite list call, per-call cost, pagination behavior, data-attestation limits, and a pointer to the schema helper. It stops short of describing what fields the case-filing detail returns, but no output schema exists to enforce 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 0% and the single parameter is a generic nested 'arguments' object with no documented properties. The description compensates by naming record_id and its source, and by directing the agent to get_cn_data_tool_schema for argument matching, but it does not enumerate the full expected 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 opening sentence states a specific verb and resource: query details of a single case-filing record (查询单条立案信息详情). It distinguishes itself from the list sibling by requiring a record_id from cn_data_v3_cases_info_list, though it does not differentiate from other detail siblings such as standard_detail or court_notice_detail.

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 a clear prerequisite: record_id must come from cn_data_v3_cases_info_list, and acquiring that list is explicitly a separate call. It does not provide when-not-to-use guidance or name alternative detail tools, but the context for correct invocation 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?

With no annotations, the description carries the full burden and does substantial work: it discloses the hard cap of 5 rows, first-page-only behavior with no pagination input, per-call cost (0.011 USDC), and explicit non-guarantees of completeness or safety. The caveats that 'empty is not a safety finding' and 'being a party does not establish liability' are valuable anti-misinterpretation guidance beyond anything structured fields provide.

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?

Purpose and the cost/pagination constraints are front-loaded, which is good. But there is clear redundancy — 'no completeness guarantee' is stated both as 'does not independently attest entity identity or completeness' and again as 'No completeness or safety guarantee' — and 'One selected Chinese company data tool call' is filler.

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?

There are no annotations and no output schema, so the description must define scope, limits, and expectations on its own — and it does, covering row cap, pagination absence, pricing, and interpretability caveats. A reader can invoke this correctly for a first-look litigation listing; only the full argument set is deferred to the schema helper.

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 0% and the single argument is an opaque object with additionalProperties:true, so the schema documents nothing. The description partially compensates by naming the required company_id and its source, and by pointing to get_cn_data_tool_schema("v3_cases_info_list") for the full argument contract, but it does not itself enumerate or explain the remaining 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 opening sentence 'Recorded corporate litigation entries' names a specific resource (litigation cases) and implies a listing, matching the _list suffix. It is clear what data comes back, but it never explicitly contrasts with the sibling cn_data_v3_cases_info_detail (single case detail), so full sibling differentiation is left to inference.

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 states a concrete prerequisite — the Jinghai company_id must come from cn_data_v3_company_detail — which is genuinely useful context. However, it gives no when-to-use / when-not guidance and never routes the agent to cases_info_detail for single-case lookups, so usage selection remains implied.

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 no annotations, the description carries the full burden and responds well: it discloses per-call cost (0.011000 USDC), that null means unknown, that a summary/header is not the underlying record list, that additional pages require separate requests, and that there is no completeness/safety guarantee. This is meaningful operational context beyond the schema.

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 purpose is front-loaded, which is good. But the remainder is a run-on block of disclaimers with redundancy — 'No ... completeness ... safety certification' and 'No completeness or safety guarantee' restate the same caveat, padding the definition.

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 a single opaque parameter and no output schema, the description covers the essentials an agent needs: what it returns (a count, not a list), where to get the identifier, pricing, and pagination behavior. Only the count-vs-overview routing and exact argument fields are missing.

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 0% and the single parameter is an opaque 'arguments' object with additionalProperties, so the schema conveys almost nothing. The description partially compensates by naming the company_id source and pointing to get_cn_data_tool_schema for the real argument contract, but it does not spell out the required fields itself.

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?

States a specific verb+resource: querying the overall count of enterprise qualification certificates. Clear enough for an agent to know what comes back (a count). However, it does not explicitly differentiate itself from the sibling cn_data_v3_certificate_overview, leaving the count-vs-overview distinction to inference.

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 actionable sourcing guidance: use company_id from cn_data_v3_company_detail and pass arguments matching get_cn_data_tool_schema("v3_certificate_count"). But it never states when to choose this count tool over certificate_overview or the other *_count siblings, so alternative selection is only implied.

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 no annotations, the description carries the full burden and delivers real substance: pricing (0.011 USDC per call), pagination behavior, and data-quality disclaimers ('null values mean unknown', 'No completeness or safety guarantee'). It does not disclose auth/permission requirements, but the cost and caveat disclosure goes well beyond the schema.

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 purpose is front-loaded, which is good, but the body is a run-on of stacked disclaimers mixing Chinese and English with repeated caveats ('No ... certification', 'No completeness or safety guarantee') that dilute the actionable content. It is not bloated enough to be unusable, but it lacks clean structure.

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 no output schema and no annotations, the definition must stand alone, and it does cover purpose, the identifier source, cost, pagination, and the summary-vs-records distinction. The opaque arguments object and absence of return-shape detail are the remaining gaps, but the essential call-correctness information is present.

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 0% and the single 'arguments' object is a free-form additionalProperties bag, so the schema provides no parameter meaning at all. The description partially compensates by naming company_id and pointing to get_cn_data_tool_schema('v3_certificate_overview'), but it does not enumerate or explain the remaining accepted arguments.

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 opening clause '查询企业证书相关概览信息' states a specific verb+resource (query enterprise certificate overview), and 'A summary/header is not the underlying record list' distinguishes it from list-returning siblings. However, it gives no explicit contrast with the adjacent cn_data_v3_certificate_count or cn_data_v3_license_list tools, so an agent must still infer the boundary.

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 tells the agent where the identifier comes from ('Use company_id from cn_data_v3_company_detail') and notes that 'Additional pages require separate requests', which is useful operational context. It never states when to choose this overview tool over the certificate_count or license_list alternatives, leaving usage largely implied.

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 no annotations, the description carries the behavioral burden and delivers real value: per-call pricing (0.011 USDC), the fact that additional pages require separate requests, and an explicit 'No completeness or safety guarantee' disclaimer. It omits auth/permission context, keeping it short of a 5.

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?

Purpose and identifier constraints are front-loaded, and the pricing/pagination/disclaimer sentences each earn their place. The line 'One selected Chinese company data tool call.' is near-redundant and the telegraphic style makes the flow choppy.

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?

There is no output schema, so the description must convey what comes back; 'Company registration and legal identity' is a vague content hint and no return fields or structure are described. Cost, pagination, and the quality caveat are covered well, but the payload shape is left to inference.

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 0% and the lone 'arguments' object is a passthrough with no documented properties, so the description must compensate. It does add the accepted identifier types (exact Chinese legal name or Jinghai company ID) and points at get_cn_data_tool_schema('v3_company_detail'), but it never enumerates the actual argument keys, leaving the agent one indirection away from the real contract.

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?

States a concrete verb/resource pair ('Company registration and legal identity') that is distinguishable from the many sibling list/count tools by naming the core entity-detail resource. It does not explicitly contrast with near-neighbors like cn_data_v3_register_header or cn_data_v3_listed_company, so it falls short of a 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?

The description gives input constraints ('Exact Chinese legal name or Jinghai company ID; no fuzzy match or direct USCC lookup'), which implicitly steer the agent toward name-resolution tooling, but it never names an alternative such as resolve_china_company. Usage context 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?

With no annotations, the description carries the full burden, and it does add real behavioral facts: per-call cost (0.011 USDC), one array return, not-guaranteed-complete history, counts/trends/headers are not underlying records, and pagination requires separate requests. That is meaningful context, though the caveats are repeated nearly verbatim ('No completeness or safety guarantee' appears twice) and no auth/permission behavior is stated.

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 text is a mixed Chinese/English run-on that interleaves the purpose statement with pricing, pagination, and repeated legal disclaimers. The duplicate 'No completeness or safety guarantee' and the schema-indirection sentence dilute the front-loaded purpose, so it is not efficiently 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?

No output schema and no annotations, and the input schema is fully undocumented, so gaps remain. The description does cover cost, pagination, and data-reliability limits and redirects to the schema tool, which is enough to call it safely-ish, but a parameter contract for a nested object should be present somewhere and is not.

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 0% on a single opaque 'arguments' object with additionalProperties=true, so the schema contributes nothing. The description partially compensates by pointing to get_cn_data_tool_schema("v3_company_tag") and naming company_id as sourced from cn_data_v3_company_detail, but it never describes the actual argument 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 opening line '查询企业规模、联系方式等标签信息' names a verb (query) and a resource (company scale/contact tag info), which is more than a tautology. But the '等' (etc.) hedging leaves the tag set ambiguous, and nothing distinguishes it from the 60+ sibling cn_data_v3_* tools. The rest of the text is boilerplate disclaimers rather than 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?

'Use company_id from cn_data_v3_company_detail' gives one input-provenance hint, and 'Additional pages require separate requests' implies pagination. However, there is no when-to-use vs. an alternative sibling, no prerequisites, and no condition that would make an agent pick this over adjacent tag/detail 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?

With no annotations, the description carries the full burden and does disclose meaningful traits: a per-call price of 0.011 USDC, the fact that the record id is verified exactly but company association is not attested, and that additional pages require separate requests. These are genuine behavioral constraints (cost, data-trust limits, pagination) rather than restated name/title text.

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 purpose is front-loaded, but the body is a run-on wall of disclaimers with clear redundancy — 'No completeness or safety guarantee' repeats the earlier completeness/safety disclaimer almost verbatim. Several clauses could be consolidated without losing meaning.

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 no output schema, no annotations, and 0% parameter coverage, the description still supplies purpose, parameter source, cost, and data-reliability caveats. An agent can credibly decide to call it, though the full argument shape still requires a secondary schema lookup.

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 0% and the single arguments object is opaque (additionalProperties, no properties), so the description must compensate. It names record_id and its source list, which is useful, but defers the rest of the argument contract to get_cn_data_tool_schema("v3_court_notice_detail") instead of describing it directly.

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 Chinese lead sentence gives a specific verb+resource (query a single court notice detail), which cleanly separates it from the record-listing sibling cn_data_v3_court_notice_list. Sibling differentiation is implied through the mention of the list tool as the record_id source rather than stated as an explicit contrast.

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 states the precondition clearly: record_id must come from cn_data_v3_court_notice_list, and acquiring that list is a separate call. That is a concrete when-to-use dependency. It stops short of naming when-not-to-use or alternatives beyond the one prerequisite.

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 no annotations, the description carries the full burden and largely meets it: it discloses the hard cap of 5 rows and no-pagination behavior, the cost (0.011 USDC per call), and interpretive caveats ("Empty is not a safety finding," "not a finding of liability"). This is well beyond what the schema provides, though it stops short of describing return field shape.

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 critical constraints (required ID, 5-row cap, cost) are front-loaded, but the tail is redundant: "The list does not independently attest entity identity or completeness" and "No completeness or safety guarantee" restate the same caveat, and the schema-pointer sentence is redundant with the schema tool's 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 list tool with no output schema and no annotations, the description supplies the operation's limits, cost, prerequisite, and data-interpretation caveats, which is nearly everything needed to call it correctly. The only gap is that the concrete argument fields are delegated to another tool rather than described here.

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 0% and the single 'arguments' object is opaque (additionalProperties: true). The description partially compensates by stating the required company_id and pointing to get_cn_data_tool_schema("v3_court_notice_list") for full argument construction, but it does not document the actual field names or formats itself.

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?

Opens with a specific resource ("Recorded court notices") and makes the list nature clear via "Provider first page only, at most 5 rows." It does not explicitly distinguish itself from the sibling cn_data_v3_court_notice_detail, so the agent must infer list-vs-detail, but the purpose is otherwise unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names a prerequisite ("Requires the Jinghai company_id from cn_data_v3_company_detail") and the pagination constraint ("Additional pages require separate requests"), which is useful. However, it never names an alternative tool or a when-not-to-use condition, so routing 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?

With no annotations, the description carries the full burden and does so: provider returns only the first page, at most 5 rows, no pagination input, additional pages need separate requests, cost is 0.011 USDC per call, and results carry no completeness/safety guarantee. These are concrete behavioral constraints an agent cannot get from schema or 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 purpose is front-loaded, but the body is padded with repetitive disclaimer boilerplate ('No completeness or safety guarantee' echoes earlier caveats) and mixes Chinese and English unevenly, so several sentences do not fully earn their place.

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 no-output-schema list tool with an opaque parameter object, the description covers the important operational realities: row cap, single page, cost, and the caveat that nonempty row semantics are unverified. It stops short of describing the returned row structure, but flags that this is unverified.

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 0% and the single 'arguments' object is opaque (additionalProperties: true), so the description must compensate. It partially does by naming company_id and pointing to get_cn_data_tool_schema('v3_court_trial_list') for the argument shape, but the full set of expected fields is left undocumented.

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 Chinese lead states a specific verb+resource: querying court-trial case numbers, causes of action, and party information (查询开庭案号、案由及当事人信息). This distinguishes it from siblings like court_notice_list or cases_info_list, but it never explicitly names a sibling to route against.

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 gives a prerequisite ('Use company_id from cn_data_v3_company_detail') and frames the call as 'one selected Chinese company data tool call,' which implies usage. However, it never states when to choose this over the many sibling list tools (court_notice_list, cases_info_list, judicial_count), so the selection guidance is only implied.

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 no annotations the description carries the full burden and does disclose substantive traits: per-call cost (0.011 USDC), that null values mean unknown, that a summary/header is not the underlying record list, and that additional pages require separate requests. This is meaningful behavioral context beyond a bare purpose.

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 purpose is front-loaded and most sentences carry information (cost, null semantics, arg source, pagination). But the legal boilerplate repeats itself ('No ... certification' followed later by 'No completeness or safety guarantee'), adding redundant bulk that dilutes the actionable parts.

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 tool with one argument and no output schema, the description covers cost, null semantics, argument sourcing, pagination, and expectation-setting disclaimers. It is largely sufficient, with the only real gap being the undisclosed internal shape of the arguments object.

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 0% and the single parameter is an opaque nested 'arguments' object, so the schema provides essentially nothing. The description partially compensates by naming company_id as the driving input and routing to get_cn_data_tool_schema for the full argument shape, but the actual parameter structure is never documented 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 opening clause '查询企业海关信息数量' (query enterprise customs information count) states a specific verb+resource with the 'count' scope, letting an agent distinguish it from list/header siblings. However, the Chinese-only purpose is followed by a wall of disclaimers that dilute focus rather than sharpen it.

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 tells the agent where to source the key argument ('Use company_id from cn_data_v3_company_detail') and that arguments must match get_cn_data_tool_schema("v3_customs_count"). It does not state when to prefer this count tool over related list/detail siblings, leaving selection to inference.

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 no annotations, the description carries the full behavioral burden and does disclose real traits: per-call cost (0.011 USDC), the fact that additional pages need separate requests (pagination), that null means unknown, and that a summary/header is not the underlying record list. The remaining disclaimers (no ownership/compliance/safety certification) are boilerplate but still convey the tool's non-authoritative nature.

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 purpose is front-loaded and the practical facts (cost, company_id source, pagination) are useful, but the text is bloated with overlapping legal disclaimers ('No ... completeness ... or safety certification' restated later as 'No completeness or safety guarantee'), which is redundancy rather than 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?

For a one-parameter count tool with no output schema and no annotations, the description covers the essentials an agent needs: what is counted, where to get the required ID, how to resolve the argument schema, the per-call cost, and pagination behavior. Only a precise statement of the argument field and its format is missing.

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 0% and the single 'arguments' parameter is an opaque nested object with additionalProperties=true. The description partially compensates by naming company_id as the needed input and by routing the agent to get_cn_data_tool_schema("v3_honor_count") for the exact argument shape, but it does not enumerate the field or its format directly.

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 opening line '查询企业荣誉数量' states a specific verb (count) and resource (enterprise honors), which is clear enough for an agent to distinguish it from list/detail siblings. However, it does nothing to differentiate itself from the many other '*_count' siblings (certificate_count, intellectual_count, standard_count), which all share an identical structural pattern.

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 one concrete prerequisite: 'Use company_id from cn_data_v3_company_detail', which tells the agent where the identifier comes from. It offers no when-to-use/when-not-to-use guidance or named alternatives among the dozens of sibling count tools, so usage is only partially implied.

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 no annotations, the description carries the full burden and does disclose meaningful traits: provider returns only the first page (up to 5 rows), no pagination input, additional pages need separate requests, per-call cost of 0.011 USDC, and an explicit disclaimer that the list does not attest identity or completeness. These are non-obvious operational constraints that go well beyond the name, though the two 'no completeness/safety' statements are near-duplicative rather than additive.

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?

Front-loading is weak (the cost and schema-pointer sentences sit mid-paragraph), and 'No completeness or safety guarantee' largely repeats 'does not independently attest entity identity or completeness'. 'One selected Chinese company data tool call' adds nothing. Some sentences earn their place, but several do not.

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 no output schema, no annotations, and a featureless arguments object, the description does cover what an agent minimally needs: prerequisite ID, page-size cap, no pagination, cost, and how to resolve the argument schema. The gaps are mostly in output shape, which is arguably out of scope here.

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 0% on a single opaque 'arguments' object, so the description must compensate; it does so partially by naming the required company_id, its source tool, and pointing to get_cn_data_tool_schema for the real argument contract. It still never documents the actual argument keys or types itself, leaving the agent dependent on an external lookup.

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 names the resource ('Recorded registration changes') but no clear verb or scope beyond that, and it never distinguishes itself from close siblings such as cn_data_v3_register_header or cn_data_v3_termination_overview. An agent can guess it returns change records for a company, but must infer the distinction.

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 supplies a real prerequisite ('Requires the Jinghai company_id from cn_data_v3_company_detail') and a route to argument discovery via get_cn_data_tool_schema, which is genuine usage guidance. However, it never says when to prefer this over the register/termination siblings, so the selection decision is left implied.

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 no annotations, the description carries the full burden and does disclose real behavior: 0.011000 USDC per single call, 'Additional pages require separate requests' (pagination), null values meaning unknown, and an explicit disclaimer that a header/summary is not the record list, with no completeness or safety guarantee. It lacks detail on response shape or failure behavior, but the cost, paging, and entity-identity caveats are genuinely useful.

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 Chinese purpose sentence is correctly front-loaded, but the English body is boilerplate-heavy and repeats the completeness/safety caveat twice ('completeness... safety certification' near the top and 'No completeness or safety guarantee' at the end). The cost and pagination facts earn their place; the duplicated disclaimers do not.

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?

There is no output schema, so the description should describe the return structure, yet it only warns that a header/summary is not the underlying record list. Cost and pagination are covered, but return-field semantics and the relationship between this count and the underlying list tools are absent for a tool whose schema is fully opaque.

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 0% for the single nested 'arguments' object, so the description must compensate. It partially does by naming company_id (via cn_data_v3_company_detail) and by pointing to get_cn_data_tool_schema("v3_intellectual_count") for the full argument set, but delegating schema discovery to a second call leaves the actual argument contract unspecified.

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 opening Chinese sentence gives a specific verb and resource set (query counts of patents, trademarks, software copyrights, and works), so an agent can tell what it returns. However, it offers no differentiation from siblings like cn_data_v3_patent_type_count or cn_data_v3_trademark_status_count, so an agent cannot tell from the description alone why it should pick this aggregate count over the type-specific ones.

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 only routing guidance is 'Use company_id from cn_data_v3_company_detail', which is parameter sourcing rather than usage guidance. There is no statement of when to prefer this tool over the many sibling count tools, nor any exclusion condition. An agent must infer placement from the name alone.

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 no annotations, the description carries the full burden and does disclose real traits: pagination ('additional pages require separate requests'), null semantics ('null values mean unknown'), cost (0.011 USDC per call), and the caveat that a summary/header is not the underlying record list. The repeated 'no certification/guarantee' disclaimers are boilerplate rather than specific, but the pagination, null and cost disclosures are genuinely useful.

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 purpose is front-loaded and the operational notes are short, but the text is padded with redundant disclaimers ('No ... completeness ... certification' and 'No completeness or safety guarantee' state the same thing twice) plus mixed-language content that 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?

For a single-purpose count tool with no output schema and an opaque argument object, the description covers what is returned (risk counts / summary), pagination, cost, and the input source. The main remaining gap is that the argument fields themselves are delegated to another schema tool rather than described here.

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 is a single untyped 'arguments' object with additionalProperties=true and 0% description coverage, so the schema explains nothing. The description partially compensates by naming company_id and pointing to get_cn_data_tool_schema for the full argument contract, but it does not document the actual arguments inline.

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 opening sentence names a specific verb+resource ('查询...司法风险计数') and enumerates the covered categories (失信、被执行、限高、裁判文书), which lets an agent distinguish it from near-neighbors like cn_data_v3_business_risk_count. It is clear, though the Chinese-only purpose statement plus trailing boilerplate slightly muddies front-loading.

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 gives a concrete prerequisite ('Use company_id from cn_data_v3_company_detail') and directs the agent to get_cn_data_tool_schema("v3_judicial_count") for argument shape, which is useful routing. It never states when to prefer this count over a sibling or when not to use it, so usage guidance stays implied.

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 no annotations, the description carries the full burden and does reasonably well: it discloses the row cap (5), the absence of pagination, that empty results are not a safety finding, per-call cost (0.011 USDC), and that additional pages need separate requests. It still omits permission/auth requirements and return shape, keeping it short of a 5.

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 purpose is front-loaded, which is good, but the body is a run-on of disclaimer boilerplate in mixed Chinese/English that reads like legal-cover text rather than agent guidance. Several sentences (ownership/compliance/safety certification disclaimers) are low-signal for tool selection and could be compressed.

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 read-only query tool with no annotations and no output schema, the description supplies the operationally important facts: the prerequisite parent call, row cap, pagination behavior, cost, empty-result semantics, and a pointer to the argument schema. Completeness is only slightly reduced by the undocumented argument contract.

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 0% and the single parameter is an opaque open object, so the schema explains nothing. The description partially compensates by pointing to the real argument contract ('matching get_cn_data_tool_schema("v3_juridical_person_company")') and by naming company_id, but it never documents the actual argument format or its source of truth inline.

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 opening Chinese clause states a specific verb and resource ('查询法定代表人关联企业、经营状态及成立日期' – query the legal representative's affiliated companies, operating status and establishment date), which is concrete and distinguishable from most of the ~60 siblings. It does not, however, contrast itself against closely related tools like cn_data_v3_key_person_list or cn_data_v3_shareholder_list, so differentiation is only partial.

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 names a prerequisite ('Use company_id from cn_data_v3_company_detail') and states the retrieval limit ('first page only, at most 5 rows, no pagination input'), which implies usage context. But there is no explicit when-to-use / when-not guidance versus the many sibling entity tools, and no exclusions are given.

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 no annotations, the description carries the full burden and does disclose meaningful traits: first page only (up to 5 rows), no pagination input, additional pages require separate requests, a per-call cost of 0.011 USDC, and an explicit disclaimer that it does not attest entity identity or completeness. Auth and return-field behavior are not covered, but the pagination and cost disclosures are substantive.

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 purpose and prerequisites are front-loaded, but the text is a run-on of stacked disclaimers and the completeness caveat is stated twice ('does not independently attest entity identity or completeness' and 'No completeness or safety guarantee'), which is redundant padding in an otherwise short definition.

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?

There is no output schema, so the description must stand alone, and it covers the key operational facts an agent needs: the required prerequisite, the one-page/5-row cap, the absence of pagination, per-call cost, and reliability caveats. It stops short of describing returned fields, but the operational picture 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 0% and the single 'arguments' object is opaque (additionalProperties true), so the description must compensate. It does so by naming the required input (Jinghai company_id) and its source, and by pointing to get_cn_data_tool_schema("v3_key_person_list") for the exact argument shape, which meaningfully fills the gap left by the empty 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 states the resource retrieved (recorded key personnel), which is clear and matches the tool name, but it uses a fragment with no explicit verb and does nothing to distinguish itself from adjacent list tools such as cn_data_v3_shareholder_list or cn_data_v3_work_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?

It gives one useful prerequisite: the Jinghai company_id must come from cn_data_v3_company_detail, implying the intended workflow. However, there is no when-to-use vs when-not guidance and no comparison against sibling tools that also return corporate personnel or entity relationships.

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 no annotations, the description carries the full burden and does substantial work: first page only, at most 5 rows, no pagination input, per-call cost of 0.011 USDC, empty result is not a safety finding, and an explicit caveat that nonempty row semantics are unverified. This is well beyond the structured data, though it doesn't describe auth/permission requirements or response field shape.

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 purpose is front-loaded and the operational facts (cost, row cap, pagination) are stated efficiently. Against that, the disclaimer block is repetitive – 'No completeness or safety guarantee' restates the earlier 'no ... completeness ... or safety certification' – and pads the description without adding new 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?

Given no output schema and no annotations, the description covers the important operational envelope: cost, first-page-only limit, row cap, the source of company_id, and explicit data-quality caveats. The only meaningful gap is that it defers the actual argument shape to another tool rather than stating it.

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 0% and the single 'arguments' object is opaque (additionalProperties: true, no properties documented). The description partially compensates by pointing to get_cn_data_tool_schema("v3_law_list") and naming company_id, but it never states the required argument fields directly, leaving real ambiguity for the caller.

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 ('查询企业裁判文书列表' – query the enterprise judgment-document list), which is concrete enough for an agent to know what it returns. However, it never distinguishes this tool from plausible siblings such as cn_data_v3_cases_info_list or cn_data_v3_court_notice_list, so the agent must infer the boundary itself.

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 gives one real prerequisite ('Use company_id from cn_data_v3_company_detail') and notes that additional pages require separate requests, which is useful routing context. But it offers no when-to-use/when-not guidance relative to the many other cn_data_v3 list tools, so usage is only implied.

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 no annotations, the description carries the full burden and delivers: result cap and no-pagination behavior, cost per call (0.011000 USDC), the caveat that an empty result is not a safety finding, that historical entries don't prove current validity, and that identity/completeness are not attested. This is unusually rich behavioral context.

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?

Front-loaded and informative, but the caveats are repetitive: 'does not independently attest entity identity or completeness' is restated as 'No completeness or safety guarantee', and 'Empty is not a safety finding' overlaps with the same idea. Trimmed, it would be tighter.

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?

No output schema exists and the input schema is a generic wrapper, but the description supplies return-scope limits, cost, and interpretation caveats that an agent needs to call and read it correctly. The only real gap is the concrete argument format, which is deferred to another 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 0% and the single 'arguments' object is opaque with additionalProperties=true. The description partially compensates by naming the required company_id and directing to get_cn_data_tool_schema("v3_license_list"), but it never documents the actual parameter shape or type.

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?

States a specific resource ('Recorded administrative licences') and makes clear it is a list keyed to a company_id, which distinguishes it from siblings like administrative_penalty or certificate_overview. It does not explicitly name an alternative tool, so it falls short of a 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?

Gives a concrete prerequisite ('Requires the Jinghai company_id from cn_data_v3_company_detail') and usage boundaries (first page only, at most 5 rows, additional pages need separate requests). It stops short of explicit when-not-to-use guidance or naming alternative 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?

With no annotations, the description carries the full burden and does disclose real traits: cost per call (0.011 USDC), that only an empty array was validated, that nonempty row semantics are unverified, that only one array is returned, and that additional pages require separate requests. This is genuine behavioral context, though the repeated hedging ('no completeness or safety guarantee' twice) dilutes 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 useful field list is front-loaded, but the body is padded with redundant legal boilerplate – 'no completeness or safety guarantee' and the completeness/identity disclaimers appear more than once. The operational information is buried under repeated hedging.

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?

There is no output schema and the input schema is opaque, so the description must cover both. It roughly describes the return (one array of listing fields) and the cost/pagination constraints, but gives no argument list and no auth or rate-limit detail, leaving the call under-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 0% and the single 'arguments' property is an opaque object with additionalProperties:true, so the description must compensate. It only hints at company_id and redirects to get_cn_data_tool_schema('v3_listed_company'); pagination and other arguments implied by 'additional pages require separate requests' are never named.

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 opening Chinese sentence states a specific verb (查询) plus the exact resource fields returned – listing date, exchange, stock code, sector, market cap – which lets an agent distinguish this listing-info tool from the many count/trend siblings. It does not explicitly name a sibling it replaces, so it stops short of a 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?

There is a concrete prerequisite – 'Use company_id from cn_data_v3_company_detail' – which tells the agent how to source the key input. However, among the ~60 sibling cn_data_v3_* tools there is no explicit when-to-use-this-vs-alternative guidance, and the 'one selected Chinese company data tool call' phrasing is vague.

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 no annotations, the description carries the full burden and delivers real behavioral facts: cost (0.011000 USDC per single call), pagination behavior (additional pages require separate requests), null semantics (null = unknown), and the warning that a summary/header is not the underlying record list. These are substantive beyond a bare schema, though the repeated 'no completeness or safety guarantee' disclaimers add noise rather than information.

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 purpose is front-loaded in the first clause, which is good, but the English block piles on overlapping negative disclaimers (freshness/completeness/ownership/safety, then 'No completeness or safety guarantee' again). Several sentences restate the same caveat instead of earning their place.

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 read-only count tool with no output schema and no annotations, the definition covers the practical essentials an agent needs: cost, pagination limits, null interpretation, and a pointer to both the argument schema tool and the company_id source. The remaining gap is the exact argument shape, which is deferred rather than missing.

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 0% and the single argument object is untyped (additionalProperties: true), so the description must compensate. It does partially by naming company_id, pointing to cn_data_v3_company_detail for its source, and delegating the full contract to get_cn_data_tool_schema("v3_media_count"), but the actual accepted fields are still not spelled out 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 Chinese lead sentence states a specific verb (查询/query) and resource (微信公众号、微博与新闻舆情数量 – WeChat, Weibo and news-opinion counts), so an agent understands it returns aggregate media-mention counts. It does not, however, differentiate itself from siblings like cn_data_v3_wechat, cn_data_v3_sina, or cn_data_v3_news_header, so it stays short of a 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?

The description steers parameter usage ("Use company_id from cn_data_v3_company_detail") and frames the tool as one selected Chinese company data call, which implies context. But it never states when to prefer this count tool over the sibling detail/list media tools, leaving the routing decision to inference.

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 no annotations, the description carries the burden well: it discloses per-call pricing (0.011 USDC), that the record id is checked exactly but company association is not attested, that additional pages need separate requests, and that no completeness/safety guarantee exists. It leaves return shape undescribed, but the behavioral caveats are unusually 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 purpose is front-loaded, but the English disclaimer block is bloated and repetitive: "completeness" is negated in the opening list and again in the closing "No completeness or safety guarantee," and the get_cn_data_tool_schema instruction is buried mid-paragraph. Several sentences do not earn their place.

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 no output schema, no annotations, and fully opaque parameters, the description adequately covers the caveats, pricing, and id provenance. However it leaves the actual argument contract entirely to an external schema tool, so an agent cannot call it correctly from this definition alone.

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 0% and the schema is an opaque {arguments: additionalProperties:true} object, so the description should compensate. It does name record_id as the key input and routes the agent to get_cn_data_tool_schema("v3_minapp_detail") for the rest, which is a reasonable workaround but not a substitute for documenting the actual 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?

"查询单个小程序详情" states a specific verb (query detail) and resource (single mini-program), and the mention of cn_data_v3_minapp_list as the id source hints at its place among siblings like cn_data_v3_app_detail. It is clear, though it never explicitly contrasts itself with the many lookalike detail tools in the sibling 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?

It states the prerequisite explicitly: a record_id must come from cn_data_v3_minapp_list and acquiring that list is a separate call. That gives clear context for when/how to invoke it, but there is no exclusion guidance (e.g., when to prefer cn_data_v3_app_detail or other detail 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?

With no annotations the description carries the full burden, and it delivers real behavioral facts: hard cap of 5 rows, first page only, no pagination input, per-call cost of 0.011 USDC, and explicit caveats that empty results are not a safety finding and no completeness/safety guarantee is offered. That is genuinely beyond what a bare schema would convey, though return format and permission needs remain unstated.

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 text is bloated with redundant disclaimers: "does not independently attest entity identity or completeness" is later restated as "No completeness or safety guarantee," and "One selected Chinese company data tool call" adds nothing. The actual purpose ("Recorded mini applications") is front-loaded but immediately buried under caveats and a schema pointer.

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 list tool with no output schema or annotations, the description covers the important operational facts: prerequisite ID source, row/pagination limits, cost, and result caveats. Return field details are omitted, but the pointer to get_cn_data_tool_schema and the explicit disclaimers keep it adequate for correct invocation.

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 is an opaque 'arguments' object (0% coverage, additionalProperties true), so the description must compensate. It partly does by naming the required key input (Jinghai company_id, sourced from cn_data_v3_company_detail) and pointing to get_cn_data_tool_schema("v3_minapp_list") for the rest, but the full argument set is left to an external lookup.

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 names the resource (mini applications) and the pagination notes ("provider first page only, at most 5 rows") make clear this is a listing/retrieval operation, distinguishable from the sibling cn_data_v3_minapp_detail. However, it never uses an explicit verb and does not contrast itself against the detail sibling, so it stops short of a 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?

It states a concrete prerequisite ("Requires the Jinghai company_id from cn_data_v3_company_detail") and notes that additional pages require separate requests, which is useful context. But there is no explicit when-to-use/when-not guidance or direction to alternatives such as minapp_detail, so usage is only implied.

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 no annotations, the description carries the full burden and does disclose meaningful behavior: null means unknown, the output is a summary/header (not the record list), cost is 0.011 USDC per call, pagination needs separate requests, and there is no completeness/safety certification. Authentication or rate-limit details are absent, keeping it short of a 5.

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 purpose sentence is appropriately front-loaded, but the body is dominated by repeated boilerplate disclaimers about certification, completeness, and safety. Several of these clauses ('No completeness or safety guarantee', 'No independent entity identity...') overlap and add length without new 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?

Given no output schema, no annotations, and an opaque single-parameter schema, the description still conveys the key operational facts: return shape (header/summary), null semantics, cost, pagination, and the company_id source. What remains thin is the argument contract, mitigated only by the pointer to get_cn_data_tool_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?

Schema description coverage is 0% with a single opaque 'arguments' object (additionalProperties: true), so the description must compensate. It partially does by naming company_id and directing the agent to get_cn_data_tool_schema("v3_news_header") for the argument shape, but it does not enumerate or explain the actual 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?

States a specific verb and resource ('查询企业新闻来源统计' – query enterprise news-source statistics) and clarifies this is a summary/header rather than the underlying record list. It distinguishes itself from record-list tools conceptually, though it never names a specific sibling such as the news list/count tools, so the differentiation is only partial.

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?

Gives one concrete prerequisite ('Use company_id from cn_data_v3_company_detail') and a pagination note ('Additional pages require separate requests'), which imply how to call it. However, it offers no explicit when-to-use vs when-not, and no guidance on choosing this over the many sibling count/header 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?

With no annotations, the description carries the full burden and does so richly: it discloses per-call cost (0.011 USDC), a hard row cap of 5 with no pagination, that additional pages need separate requests, that an empty result is not a safety finding, that only an empty page was survey-validated, and that it carries no identity/freshness/completeness/certification guarantee. This is exactly the behavioral context an agent needs.

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 purpose line is well front-loaded, but the body is a dense run-on of disclaimers with repetition ('No completeness or safety guarantee' overlaps with the earlier no-certification line, and 'Additional pages require separate requests' restates the pagination note). Information is useful but not tightly 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?

Considering no output schema and no annotations, the description covers cost, pagination limits, ID sourcing, and validity caveats well enough for correct invocation. It could still be clearer about what a populated row contains given the acknowledged unverified semantics.

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 single nested 'arguments' object has 0% schema coverage, but the description compensates meaningfully by naming the key field (company_id), its source tool, and by pointing to get_cn_data_tool_schema for the exact argument shape. That is strong guidance for an otherwise opaque 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 opening Chinese sentence states a specific resource and what is returned: reasons, dates, and removal info for the business abnormality/operation-exception directory. It clearly names the domain, though it does not explicitly distinguish itself from near-neighbour siblings such as business_risk_count or administrative_penalty beyond the resource name.

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 gives one concrete dependency: 'Use company_id from cn_data_v3_company_detail,' which tells the agent how to source the key input. However, it never states when to prefer this tool over related risk/penalty siblings or what conditions warrant calling it, so usage is only implied.

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 no annotations, the description carries the full behavioral burden and does a decent job: it discloses return shape (one array), that history is not guaranteed complete, that counts/trends/headers are not underlying records, that additional pages require separate requests, and an explicit per-call cost (0.011 USDC). That is real behavioral context beyond structured fields. It only lacks clarity on auth/permissions and exact pagination mechanics.

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 purpose is front-loaded, but the body is a run of terse fragments with duplicated boilerplate ('No completeness or safety guarantee' appears twice, plus a near-duplicate disclaimer at the top). The cost/pagination/param-guidance sentences earn their place; the repeated disclaimers do not.

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 no output schema and no annotations, the description covers return shape, cost, caveats and the company_id source, which is respectable. But the parameter contract is left to an external schema tool, so an agent cannot invoke this correctly from the definition alone.

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?

Coverage is 0% and the only parameter is an opaque nested 'arguments' object, so the description must compensate. It partially does by naming company_id and pointing to get_cn_data_tool_schema('v3_patent_apply_trend') for argument shapes, but it never enumerates the accepted argument names or formats, leaving the actual call signature underspecified.

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 opening sentence states a specific verb+resource+dimension: querying the year trend of patent applications. This is distinguishable from siblings like patent_publication_trend, patent_type_count and patent_header by naming the trend dimension (application-year) rather than publication or type. It stops short of explicitly contrasting itself with those 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?

It tells the agent to source company_id from cn_data_v3_company_detail and that this is 'one selected Chinese company data tool call', which implies scope. However there is no explicit when-to-use vs. when-to-use-an-alternative (e.g. vs. patent_publication_trend or patent_header), and no exclusions.'

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 no annotations, the description carries the full burden, and it does disclose useful behavior: a header is not the underlying record list, null means unknown, additional pages require separate requests, and the per-call cost is 0.011 USDC. However, much of the text is boilerplate legal disclaimer repeated at both ends, diluting the genuinely informative parts.

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 purpose is front-loaded, which is good, but the body is bloated with redundant disclaimers ('no completeness or safety guarantee' recurs, and the opening liability sentence is restated at the end). Several sentences repeat the same non-guarantee rather than adding 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?

Given no output schema, no annotations, and a fully opaque argument schema, the description covers pricing, pagination, the header-vs-list distinction, and parameter sourcing, but omits what fields the header actually returns and whether company_id is mandatory, leaving real gaps for a data-retrieval 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 description coverage is 0% with a single opaque nested 'arguments' object. The description names company_id and redirects to get_cn_data_tool_schema for details, which is a small amount of added meaning, but it never states that company_id is required, its format, or what other arguments the object accepts.

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 opening sentence '查询专利法律状态和专利类型概览' states a specific verb and resource (patent legal status and type overview). It is clear what the tool returns, but it does not differentiate itself from siblings like cn_data_v3_patent_law_count or cn_data_v3_patent_type_count, which appear to cover overlapping sub-topics.

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 only actionable guidance is 'Use company_id from cn_data_v3_company_detail', which is really an input-construction hint. There is no statement of when to choose this header over the many sibling patent/count/list tools, nor any exclusion or alternative 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?

With no annotations, the description carries the full behavioral burden and does disclose several useful traits: cost (0.011 USDC per call), that only one array is returned, that history may be incomplete, and that additional pages require separate requests. It says nothing about permissions/auth or the shape of returned fields, so the disclosure is partial rather than thorough.

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 useful purpose statement is front-loaded, but the remainder is padded boilerplate: the completeness/safety caveat is stated twice ('not guaranteed complete history' and 'No completeness or safety guarantee'), and generic disclaimer sentences dilute the actionable content. Multiple sentences do not earn their place.

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 opaque parameters, no output schema and no annotations, the description does cover cost, pagination, the company_id source and a schema-discovery pointer. It still leaves the actual argument list and return structure undocumented, so an agent needs a second lookup call before it can use this reliably.

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 0% and the single 'arguments' property is an opaque object with additionalProperties=true, so the schema provides essentially nothing. The description partially compensates by naming company_id as the key input and pointing to get_cn_data_tool_schema("v3_patent_law_count") for the full argument shape, but it never enumerates the actual required 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 Chinese phrase '查询专利法律状态统计' states a specific verb (query) and resource (patent legal status statistics), which is far more informative than the machine name alone. However, it does nothing to differentiate this tool from the many neighboring patent tools (cn_data_v3_patent_type_count, cn_data_v3_patent_apply_trend, cn_data_v3_patent_header), so an agent still has to guess which patent metric it wants.

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?

'Use company_id from cn_data_v3_company_detail' and 'One selected Chinese company data tool call' give real context about the expected input source and call granularity. There is still no when-to-use/when-not guidance relative to the sibling patent count/trend tools, so usage is only partially implied by the surrounding boilerplate.

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 no annotations, the description carries the full burden and it does disclose real behavior: a single returned array, that counts/trends/headers are not underlying records, that history is not guaranteed complete, that additional pages require separate requests, and a per-call cost of 0.011 USDC. These are genuinely useful operational facts, though auth/permission requirements and rate limits are still unstated.

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 purpose is front-loaded, but the body is padded with repetitive legal boilerplate ('No completeness or safety guarantee' and the entity-identity disclaimer convey overlapping meaning). Several sentences restate the same limitation rather than adding new 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?

With no annotations and no output schema, the description does reasonably cover output shape (one array), pagination, cost, and data-completeness caveats. It is still thin on the return fields and on required authorization, so it is adequate but not fully complete for a data-retrieval 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 description coverage is 0% and the only surfaced parameter is a generic 'arguments' object, so the description must compensate. It names one meaningful field (company_id) and its source tool and points to get_cn_data_tool_schema for the full argument set, which is partial but better than nothing — it does not document the remaining nested arguments.

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 opening line '查询专利公开年份趋势' states a specific verb+resource (query patent-publication year trend), which is clear enough for an agent to know the operation. However, it never distinguishes itself from the closely related sibling cn_data_v3_patent_apply_trend, leaving the publication-vs-application boundary to inference.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives such as cn_data_v3_patent_apply_trend. The only contextual hint is 'Use company_id from cn_data_v3_company_detail', which explains input sourcing but not tool 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?

With no annotations, the description carries the full behavioral burden and does disclose meaningful traits: "One returned array", "not guaranteed complete history", "Counts/trends/headers are not underlying records", "Additional pages require separate requests", and an explicit per-call cost of 0.011000 USDC. Missing are what the returned array elements look like and any auth/permission requirements, so it is strong but not exhaustive.

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 statement is front-loaded, but the body is boilerplate-heavy and redundant: "No completeness or safety guarantee" duplicates the earlier "no ... completeness ... or safety certification" list item, and "One selected Chinese company data tool call" adds no information. The useful company_id routing hint is buried mid-paragraph.

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 one-parameter count tool with no output schema, the description covers cost, pagination behavior, data-completeness caveats, and where the ID argument comes from, and it delegates argument detail to get_cn_data_tool_schema. It still leaves the shape/content of the returned array unexplained, which matters since there is no 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?

There is one nested 'arguments' object with 0% schema description coverage, so the schema explains nothing. The description partially compensates by naming company_id as an input sourced from cn_data_v3_company_detail and by directing the agent to get_cn_data_tool_schema("v3_patent_type_count") for the full argument contract, but it does not enumerate the parameters itself.

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 opening Chinese sentence "查询专利类型分布统计" states a specific verb (query) and resource (patent type distribution statistics), which is far clearer than a tautology. However, it does not distinguish this from near-siblings such as cn_data_v3_patent_apply_trend, cn_data_v3_patent_law_count, or cn_data_v3_trademark_type_count, so an agent must infer the boundary from the suffix alone.

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 one concrete usage hook - "Use company_id from cn_data_v3_company_detail" - which tells the agent where the key identifier comes from. It never states when to choose this tool over the other patent/trademark count and trend siblings, so the usage context is only implied by the name.

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 no annotations, the description carries the full burden and does well: it discloses the first-page-only limit (max 5 rows, no pagination), the per-call cost of 0.011 USDC, that empty results are not safety findings, and explicitly that nonempty row semantics are unverified. It stops short of 5 only because return shape is left unspecified.

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 purpose is front-loaded in the first line, but the remainder is a dense, somewhat repetitive wall of caveats ('No completeness or safety guarantee' restates the earlier certification disclaimer). It is defensible but could be tightened without losing behavioral content.

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 no annotations, no output schema, and an opaque free-form parameter, the description does substantial work covering cost, pagination limits, and safety caveats. It remains incomplete on what a returned row actually contains, which matters for an unverified-semantics 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 0% and the single 'arguments' object is free-form with additionalProperties true, so the schema carries no meaning. The description compensates partially by naming company_id and pointing to get_cn_data_tool_schema("v3_promotion_keyword") for the actual argument contract, but the caller must still make a second lookup call.

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 opening line states a clear verb+resource: 'query enterprise online promotion keywords', which is specific enough to distinguish it from most siblings. It doesn't explicitly differentiate from the closely related cn_data_v3_promotion_overview sibling, so it stops short of a 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?

It gives operational context ('Use company_id from cn_data_v3_company_detail', 'One selected Chinese company data tool call', 'Additional pages require separate requests') but never states when to choose this over the promotion_overview sibling or other company data tools. Usage is implied by the survey framing rather than spelled out.

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 no annotations, the description carries the full burden and does disclose real behavioral traits: per-call pricing (0.011 USDC), that additional pages require separate requests, that null means unknown, that a summary/header is not the underlying record list, and explicit data-quality/ownership/compliance disclaimers. It omits auth/permission requirements, but the pricing, pagination and null semantics are substantive beyond a bare restatement.

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 purpose is front-loaded, but the body is a run-on mix of Chinese and English with overlapping disclaimers ('No completeness or safety guarantee' repeats the earlier completeness/safety certification clause). Several sentences earn their place (pricing, pagination, null semantics), but the framing is somewhat disorganized.

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 no output schema and an opaque single-argument schema, completeness rests on the description, which does hint at return shape ('A summary/header is not the underlying record list') and gives cost/pagination caveats. It still leaves the concrete return structure and argument fields to the separate get_cn_data_tool_schema call, so it is adequate rather than self-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 coverage is 0% and the schema is an opaque 'arguments' object with additionalProperties, so the description must compensate. It names the key field (company_id), its source (cn_data_v3_company_detail), and points to get_cn_data_tool_schema('v3_promotion_overview') for the full argument shape, which is helpful but leaves the actual argument structure to an external lookup.

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 Chinese opening () states a specific verb (query) and resource (enterprise online promotion overview), which an agent can distinguish from keyword-level siblings like cn_data_v3_promotion_keyword. However, it stops short of naming any sibling or clarifying the boundary of 'overview' vs. detail tools, leaving differentiation to inference.

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 supplies a concrete prerequisite: 'Use company_id from cn_data_v3_company_detail,' routing the agent to how the key argument is obtained, and notes it is 'One selected Chinese company data tool call.' It gives no explicit when-not guidance or comparison against the sibling promotion/data tools, so usage is implied rather than directive.

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 no annotations, the description carries the full behavioral burden and does add some value: null means unknown, a summary/header is not the underlying record list, and there is no completeness/safety guarantee. It omits any recovery/rate behavior beyond pricing, so it is adequate but incomplete.

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 purpose is front-loaded, but the text repeats itself: "No independent entity identity, freshness, completeness ... or safety certification" and again "No completeness or safety guarantee." That redundancy and the mixed-language boilerplate are not earning their place.

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 1-param, no-output-schema, no-annotation tool the description does cover pricing, pagination, null semantics, and the origin of company_id. But the deferred schema resolution and the opaque arguments object leave the agent without enough to construct a call confidently.

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 0% and the single parameter is an opaque nested object with additionalProperties=true. The description only hints at company_id and otherwise defers to get_cn_data_tool_schema("v3_recruit_count") rather than documenting the actual arguments, so it does not compensate for the coverage gap.

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 opening line "查询企业招聘岗位数量与概览" states a specific verb (query/count) and resource (company recruitment positions), making it distinguishable from list/detail siblings like cn_data_v3_work_list. It is clear but does not explicitly contrast itself with the other *_count siblings, so it stops short of a 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?

It gives one actionable prerequisite: "Use company_id from cn_data_v3_company_detail." It also notes that additional pages require separate requests. However, it offers no when-to-use/when-not guidance against the many competing count siblings (certificate_count, bid_count, etc.).

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?

No annotations are provided, so the description carries the full burden. It does disclose useful behavioral traits: no identity/freshness/completeness/ownership certification, null means unknown, per-call pricing (0.011000 USDC), and no completeness/safety guarantee. That is real added context, but the same disclaimer is repeated and nothing is said about response structure or rate limits beyond 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?

The purpose is front-loaded and readable, but the body repeats the same no-guarantee disclaimer twice and interleaves Chinese and English disclaimers, making it bloated for the amount of unique information conveyed.

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 header/statistics tool with no output schema, the description covers pricing, pagination behavior, the identity/completeness caveats, and where to obtain the argument schema. An agent has enough to invoke it correctly, though the argument detail relies on an external schema lookup rather than being self-contained.

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 0% and the single parameter is a generic 'arguments' object with additionalProperties=true, so the schema provides essentially no semantics. The description partially compensates by pointing to get_cn_data_tool_schema("v3_register_header") and mentioning company_id, but it does not document the actual argument names/types inline.

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 Chinese phrase states a specific verb and resource: 查询 (query) 建筑资质注册人员类别统计 (construction-qualification registered-personnel category statistics). It also distinguishes itself from list-type siblings by noting 'A summary/header is not the underlying record list.' It is clear, though the mixed-language phrasing leaves the exact output shape somewhat 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?

It gives a concrete precondition — 'Use company_id from cn_data_v3_company_detail' — and notes that additional pages require separate requests. However it never names a sibling to prefer or avoid, and does not state when this header is preferable to the underlying list tool, so usage is only partially guided.

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 no annotations, the description carries the full burden and does substantial work: it discloses the first-page-only cap (up to 5 rows), the absence of pagination input, the per-call cost (0.011000 USDC), and explicit disclaimers about identity/completeness attestation and safety guarantees. It does not cover authentication or error behavior, keeping it out of the top tier.

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 purpose and key constraint are front-loaded, but the text is bloated by restated disclaimers – 'The list does not independently attest entity identity or completeness' and 'No completeness or safety guarantee' convey overlapping caveats, and the pricing sentence interrupts the flow.

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 no output schema and a nested, undocumented argument object, the description supplies the essential operational context an agent needs: data dependency, page-size ceiling, no pagination, and cost. It stops short of fully specifying the argument payload, which is delegated to another 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 0% and the lone 'arguments' object is opaque (additionalProperties: true, no property descriptions). The description partially compensates by naming the required company_id from cn_data_v3_company_detail, but it defers the actual argument structure to get_cn_data_tool_schema('v3_shareholder_list') rather than documenting it inline, so gaps remain.

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 opening sentence names a specific resource ('Recorded shareholders') and ties it to the company_id sourced from cn_data_v3_company_detail, so the agent knows this returns a shareholder roster. It is distinguishable from sibling list tools by resource, though it never explicitly contrasts with near neighbors like key_person_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?

It states a prerequisite (Jinghai company_id from cn_data_v3_company_detail) and notes that additional pages require separate requests, which is useful context for when this tool applies. However, it gives no explicit when-not guidance or comparison against alternative tools that return related entity 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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses that the provider offers no independent entity identity, freshness, completeness, ownership, compliance or safety certification; that results are first-page-only with at most 5 rows; that empty results are not safety findings; that total count is omitted; and that calls cost 0.011 USDC apiece.

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 purpose is front-loaded and the caveats are information-dense, but the text repeats itself: the opening disclaimer and the closing 'No completeness or safety guarantee' duplicate the same idea, and 'One selected Chinese company data tool call' is vague filler.

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 an opaque data-retrieval tool with no output schema and no annotations, the description supplies the essential operating constraints: cost, pagination limits, row cap, empty-result interpretation, and where to find the required company_id. It leaves return fields unspecified, but the provider limitations are sufficiently disclosed that an agent can invoke it responsibly.

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 0% and the single parameter is an opaque nested 'arguments' object. The description partially compensates by instructing the agent to pass arguments matching get_cn_data_tool_schema("v3_sina") and by naming company_id as a field sourced from cn_data_v3_company_detail, but it does not document the expected argument structure or syntax.

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 Chinese sentence clearly states the tool queries enterprise/institution Weibo information, giving a specific verb and resource. It distinguishes itself from company_detail by telling the agent to source company_id from that sibling, but it does not explicitly contrast itself with other media or news 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?

It supplies a concrete prerequisite (use company_id from cn_data_v3_company_detail) and usage limits (provider first page only, at most 5 rows, no pagination input, additional pages require separate requests). It lacks explicit when-not-to-use guidance or direct sibling alternatives, but the operational context 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?

With no annotations, the description carries the full burden and does substantial work: it discloses cost (0.011000 USDC per call), a hard truncation to the first page of up to 5 rows, and that results do not attest entity identity or completeness. It is slightly muddled because "no pagination input" sits awkwardly beside "additional pages require separate requests," and the completeness disclaimer is repeated.

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?

Purpose is front-loaded, which is good, but the text is choppy and repetitive — pagination limits are stated twice and the no-completeness/no-identity caveat twice. The price is written with excessive precision (0.011000) and several sentences could be merged without losing 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?

With no output schema and no annotations, the description supplies the key operational facts an agent needs: dependency on company_detail, row cap, no paging, per-call cost, and reliability caveats. Return-value structure is not described, but the description does indicate what the rows represent.

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 0% and the single nested 'arguments' object is opaque (additionalProperties: true), so the description must compensate. It does name the required value (company_id from cn_data_v3_company_detail) and redirects to get_cn_data_tool_schema for the full argument shape, but leaves the remaining argument fields unexplained.

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?

States the resource precisely — recorded software copyrights — which distinguishes it from sibling tools covering patents, trademarks, and standards. The verb is implied rather than stated (it reads as a noun phrase), but an agent can still tell what data class this returns.

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?

Gives a clear prerequisite — company_id from cn_data_v3_company_detail — and points to get_cn_data_tool_schema("v3_software_list") for argument shape, which establishes the call context. It offers no exclusions or comparison against alternative software/IP tools, so it falls 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?

With no annotations, the description carries the full burden and does disclose several non-obvious behaviors: per-call pricing (0.011 USDC), that additional pages require separate requests, that null means unknown, and that a summary/header is not the underlying record list. It omits auth requirements and return-format details, but for a count endpoint the cost, pagination, and null semantics are substantive disclosures.

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 purpose is front-loaded well, but the body is padded with repetitive disclaimer boilerplate ('No independent entity identity...' and 'No completeness or safety guarantee' effectively restate each other). Several sentences do not earn their place, diluting an otherwise short definition.

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 genuinely simple count tool with no output schema, the description covers the essentials: data source, cost, pagination behavior, and null semantics. The only gap is that concrete argument details are deferred to get_cn_data_tool_schema, which is an acceptable resolution path rather than a missing piece.

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 0% and the input schema is an opaque 'arguments' object with additionalProperties, so the schema does no work. The description partially compensates by naming the key parameter (company_id) and routing the agent to get_cn_data_tool_schema('v3_standard_count') for the full argument list, but it does not itself document the arguments.

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 opening sentence '查询企业标准数量' states a specific verb and resource (query the count of enterprise standards), which is clear enough to distinguish a count tool from the standard_list and standard_detail siblings by name. However, it never explicitly names or contrasts those siblings, so the differentiation is inferred rather than 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 description provides a prerequisite/data-source hint ('Use company_id from cn_data_v3_company_detail'), which is genuinely useful usage context. It stops short of saying when to choose this count tool over cn_data_v3_standard_list or standard_detail, so guidance remains 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?

With no annotations, the description carries the full burden and does well: it discloses that there is no independent attestation of entity identity, freshness, completeness, or compliance, that the record id is matched exactly but not attested to the company, and it states the per-call cost. Missing details about return shape, but the disclosure standard is met.

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?

Purpose is front-loaded, but the body piles on hedged disclaimers with noticeable redundancy — 'No completeness or safety guarantee' repeats an earlier 'no ... completeness ... or safety certification.' The value density is lowered by this repetition.

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 an opaque, single-argument detail tool with no output schema and no annotations, the description covers the key gaps: prerequisite source of record_id, exact-match caveat, cost, pagination, and a pointer to the schema tool. Only the concrete argument format is left unaddressed.

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 0% and the single 'arguments' object is fully opaque (additionalProperties: true), so the description must compensate. It names record_id as required via the sibling list and points to get_cn_data_tool_schema('v3_standard_detail') for the true schema, but it does not describe the field's format or any other accepted arguments.

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 Chinese opener '查询单条企业标准详情' states a specific verb and resource (query a single company-standard record), clearly distinguishing it from siblings cn_data_v3_standard_list and cn_data_v3_standard_count. It is clear enough for an agent to identify it as the detail-fetch counterpart, though it does not explicitly name those 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?

It states the prerequisite explicitly: 'Requires record_id from cn_data_v3_standard_list; acquiring that list is a separate call,' which routes the agent to the correct sequence. It also covers pagination ('Additional pages require separate requests') and pricing. It stops short of explicit when-not-to-use guidance, hence a 4.

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 no annotations, the description carries the full load and does so well: first-page-only cap of 5 rows, no pagination input, empty result is not a safety finding, no completeness/freshness/identity guarantee, and a per-call cost of 0.011 USDC. These are exactly the traits an agent cannot get from structured fields.

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?

Purpose is correctly front-loaded, but the caveats are repetitive: 'No completeness or safety guarantee' restates the earlier 'no independent entity identity, freshness, completeness...' and 'Empty is not a safety finding'. Several clauses could be merged without losing meaning.

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 no annotations, no output schema, and an opaque argument bag, the description covers behavior, cost, and result limits, and routes the agent to the schema tool for parameter structure. It is reasonably complete for a small lookup tool, with the argument contract being the only real hole.

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 0% and the single 'arguments' object is an opaque additionalProperties bag, so the description must compensate. It does point to company_id as the source (cn_data_v3_company_detail) and redirects to get_cn_data_tool_schema for the argument shape, but it never describes the fields inside the arguments object.

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?

States a specific verb+resource: query enterprise standard name, level, and status, which is enough to distinguish it from standard_count (numeric rollup) and standard_detail (single record). It never names those siblings, so differentiation is inferred rather than explicit.

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?

Gives a prerequisite (use company_id from cn_data_v3_company_detail) and a hard usage constraint (provider first page only, max 5 rows, no pagination input). It does not say when to prefer this over cn_data_v3_standard_count or cn_data_v3_standard_detail, so the choice among the three standard tools is left implicit.

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?

No annotations are provided, so the description carries the full behavioral burden, and it does disclose several real traits: null values mean unknown, a summary/header is not the underlying record list, additional pages require separate requests (pagination), and per-call cost. It stops short of stating authorization or read-only status, and the legalistic boilerplate is vague.

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?

Purpose is front-loaded in the first sentence, but the remainder is a run-on chain of disclaimer fragments that repeats itself ('No independent entity identity, freshness, completeness...' and 'No completeness or safety guarantee' say nearly the same thing). Signal is diluted by boilerplate that could be a single disclaimer.

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 no output schema, the description should characterize returns, and it nominally does (taxpayer type, status, basic tax info) plus adds cost, pagination, and null semantics. For a single-company data lookup against an opaque argument object it is minimally adequate, though the actual field list and argument names remain undisclosed.

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 is an opaque one-property object at 0% description coverage, so the schema provides essentially nothing. The description compensates by directing the agent to get_cn_data_tool_schema("v3_tax_basic") for the argument shape and by naming company_id as the key input, but it does not itself document the 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 opening Chinese sentence states a specific verb+resource: it queries taxpayer type, status, and basic tax information for one company. That is clear on its own, but the description never explicitly distinguishes this from sibling tax tools (cn_data_v3_tax_credit, cn_data_v3_tax_overdue, cn_data_v3_tax_punishment_list), so the agent must infer the split from the names.

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 gives a concrete access hint: use company_id from cn_data_v3_company_detail, which tells the agent where the required input comes from. However, it gives no when-to-use-vs-alternatives guidance against the other tax-related siblings, leaving selection to the agent's inference.

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 no annotations, the description carries the full burden and delivers real operational context: first page only, at most 5 rows, no pagination input, additional pages require separate requests, and per-call cost of 0.011 USDC. It also flags semantic limits (empty is not a safety finding, recorded grade is not current compliance certification), though it omits error/auth behavior.

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 purpose and row limits are front-loaded, which is good, but the text is a run-on run of fragments and repeats its completeness/safety caveat twice ('does not independently attest... completeness' and 'No completeness or safety guarantee'). Several sentences could be consolidated.

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 an opaque-schema tool with no annotations and no output schema, the description covers scope, row limits, cost, and caveats reasonably well. The main gap is that the actual callable arguments are delegated to another tool rather than explained, leaving the invocation under-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 0% and the schema is an open nested object with additionalProperties, so the description must compensate. It does name the key identity parameter (company_id) and its source, and routes the agent to get_cn_data_tool_schema("v3_tax_credit"), but the actual argument shape is not described.

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?

States a specific verb+resource and scope: 'Recorded tax-credit grades by year.' The resource is distinguishable from siblings like tax_basic, tax_overdue, and tax_punishment_list. It does not explicitly name alternatives, but the subject matter is clear enough for an agent to select it.

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 one concrete prerequisite: the company_id must come from cn_data_v3_company_detail, which is useful routing. However, it gives no explicit when-to-use/when-not guidance versus the many other cn_data_v3 tax tools, and the 'One selected Chinese company data tool call' line is vague rather than directive.

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 no annotations, the description carries the full burden and does substantial work: provider first page only, at most 5 rows, no pagination input, 0.011 USDC per call, empty is not a safety finding, and nonempty row semantics are unverified. It omits auth/permission requirements and error behavior, so it stops short of complete 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 purpose is front-loaded in the first line, which is good, but the remainder is a dense block of boilerplate caveats with visible redundancy ('completeness... certification' restated later as 'No completeness or safety guarantee'). Every sentence is informative, yet the repetition costs structure.

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 no annotations, no output schema, and an untyped nested parameter, the description supplies cost, row/pagination limits, a prerequisite source for the entity id, and verification caveats, plus the returned field names. It is close to complete; the missing pieces are auth expectations and the exact argument keys.

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 0% and the schema is an opaque 'arguments' object with additionalProperties, so the description must compensate. It does name the key input (company_id from cn_data_v3_company_detail) and directs the agent to get_cn_data_tool_schema for the exact shape, but it never enumerates or explains the parameter set itself.

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 opening line states a specific verb+resource (查询欠税 = query overdue tax) and even names the returned fields (amount, announcement date, tax authority), so the agent knows exactly what the tool produces. However, it never distinguishes itself from close tax siblings like cn_data_v3_tax_basic, cn_data_v3_tax_credit, or cn_data_v3_tax_punishment_list, leaving sibling selection to inference.

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 gives one concrete prerequisite – obtain company_id from cn_data_v3_company_detail – and implies the tool is one-of-many via 'One selected Chinese company data tool call'. But it offers no explicit when-to-use/when-not-versus the other tax tools, so the agent must guess which tax endpoint fits a given need.

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 no annotations, the description carries the full burden and does substantial work: it discloses the 5-row/one-page cap, no pagination, that empty results are not a safety finding, that only an empty page was survey-validated and nonempty row semantics are unverified, and the per-call cost (0.011 USDC). It still omits auth/permission needs and the returned field structure.

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?

Purpose is front-loaded, which is good, but the body is a dense run of mixed Chinese/English caveats with some redundancy ('No completeness or safety guarantee' echoes earlier hedging). Sentences mostly earn their place as risk disclaimers, but the block is heavier than needed.

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 no-annotation, no-output-schema tool, the description covers scope, coverage limits, cost, and the ID prerequisite, and it honestly flags that row semantics are unverified. The main remaining gap is what fields come back, though the explicit 'semantics not yet independently verified' caveat partially absolves 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 coverage is 0% and the single 'arguments' property is a free-form object (additionalProperties: true), so the schema documents nothing. The description partly compensates by pointing to get_cn_data_tool_schema('v3_tax_punishment_list') and by naming company_id as the expected input, but actual parameter names and semantics remain unspecified.

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 opening sentence names a specific verb+resource in Chinese (查询税务重大违法案件与公布信息 = query tax major-violation cases and publication info), which is distinct from siblings like cn_data_v3_tax_basic, tax_credit, and tax_overdue. It does not, however, explicitly contrast itself against those siblings to route the agent.

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 gives concrete usage context: 'Use company_id from cn_data_v3_company_detail' establishes the prerequisite ID source, and 'Additional pages require separate requests' plus 'provider first page only, at most 5 rows, no pagination input' tells the agent what it cannot do. No explicit when-not or named alternative tool is offered.

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 no annotations, the description carries the full burden and does reasonably well: it discloses cost (0.011 USDC per single call), that one call returns one company's data, that additional pages require separate requests, and that null means unknown. Safety/completeness caveats are stated, though repetitively.

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 purpose is front-loaded, but the body is a run-on of disclaimers with redundancy ('no ... completeness ... certification' and again 'No completeness or safety guarantee'). Several sentences restate the same limitation instead of earning their place.

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 1-parameter tool with no output schema, the description covers purpose, the parameter source, schema discovery, pricing, pagination, and null semantics. Return detail is light, but the summary-vs-list caveat partially compensates for the absent 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?

Schema coverage is 0% and the single parameter is an opaque free-form 'arguments' object, so the description must compensate. It does so by pointing to get_cn_data_tool_schema("v3_termination_overview") for the real argument shape and by naming company_id as a required input sourced from company_detail.

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 opening states a specific verb+resource: query an overview of terminated-enforcement case amounts and fulfillment status (终本案件金额和履行情况概览). It also explicitly distinguishes itself from list-type siblings by noting 'A summary/header is not the underlying record list.' Clear, though the surrounding boilerplate dilutes it.

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 a prerequisite for the key input ('Use company_id from cn_data_v3_company_detail') and a pagination hint, but gives no explicit when-to-use/when-not guidance versus related siblings like cn_data_v3_cases_info_list or cn_data_v3_judicial_count. Usage is implied, not directed.

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 no annotations, the description carries the full behavioral burden, and it does disclose limitations: no completeness/freshness/safety guarantee, counts/trends/headers are not underlying records, one array returned, per-call pricing (0.011 USDC), and per-page requests. These are generic boilerplate rather than tool-specific traits, and it says nothing about auth or error behavior, so it is adequate 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?

Purpose is front-loaded correctly in the first clause, but the remainder is repetitive: the completeness/safety disclaimer appears twice ('not guaranteed complete history' and 'No completeness or safety guarantee'), and pricing/pagination notes are boilerplate likely duplicated across every v3 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 no-output-schema tool it does state the return shape ('One returned array') and the data-limitation caveats, plus cost and pagination. What is missing is any sense of what the trend values contain or how to select this tool versus the register/status/type trademark 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?

Schema description coverage is 0% and the schema is an opaque 'arguments' object, so the description must compensate. It partially does by naming company_id and pointing to get_cn_data_tool_schema("v3_trademark_apply_trend") for the real argument shape, but it does not enumerate or explain the actual parameters itself.

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 Chinese phrase '查询商标申请年份趋势' states a specific verb (query), resource (trademark applications) and dimension (year trend), which separates it from count-oriented siblings like cn_data_v3_trademark_status_count and cn_data_v3_trademark_type_count. It does not explicitly distinguish itself from the close sibling cn_data_v3_trademark_register_trend (apply vs. register), so it stops short of a 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?

It gives a concrete input prerequisite ('Use company_id from cn_data_v3_company_detail') and a pagination note ('Additional pages require separate requests'), which is real usage guidance. However it never states when to prefer this tool over trademark_register_trend or the trademark count tools, so the alternative-selection condition is left to inference.

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 no annotations, the description carries the full burden and does unusually well: it discloses one-array return shape, that history is not guaranteed complete, that counts/trends/headers are aggregated rather than underlying records, that additional pages require separate requests, and a per-call cost of 0.011 USDC. It stops short of describing permissions, error behavior, or latency, so it is strong but not exhaustive.

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 genuine content (purpose, input source, cost, pagination, completeness caveat) is front-loaded, which is good. But the middle is heavy boilerplate about entity identity, ownership, compliance, and safety certification that repeats itself ('No completeness or safety guarantee' restates an earlier clause) and dilutes the signal.

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 no output schema and no annotations, the description supplies the return shape (one array), the aggregation caveat, the required input source, the pagination rule, and the price — enough for an agent to call it correctly and interpret results. Only the array's field-level contents and error conditions remain unexplained.

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 single parameter is an opaque 'arguments' object with additionalProperties=true and 0% schema coverage, so the schema documents nothing. The description partially compensates by naming company_id as the key input and redirecting to get_cn_data_tool_schema, but it never states the accepted argument names or types inline, leaving real ambiguity.

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 opening line names a specific verb and resource (query trademark registration year trend), which is clear and distinct from count-type siblings. However, it never differentiates itself from the very similar cn_data_v3_trademark_apply_trend (registration vs. application trend), which is the one distinction an agent actually needs.

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 only implied by the prerequisite hint 'Use company_id from cn_data_v3_company_detail' and the pointer to get_cn_data_tool_schema for argument shape. There is no statement of when to prefer this over trademark_apply_trend, trademark_status_count, or trademark_type_count, and no exclusions.

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 no annotations, the description carries the full burden and does meaningfully discharge it: it discloses cost (0.011 USDC per call), return shape (one array), that counts are not underlying records, that completeness/freshness/ownership are not guaranteed, and that extra pages cost separate requests. It omits auth requirements and what the statuses actually are, but the disclosure is well above boilerplate.

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 purpose is front-loaded in one clean sentence, but it is followed by a long run of generic disclaimers that partly repeat themselves ('not guaranteed complete history' vs. 'No completeness or safety guarantee'). Several sentences are shared boilerplate rather than tool-specific content.

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 no annotations, no output schema, and a nested untyped argument object, the description supplies the essentials (cost, prereq, return shape, caveats) but leaves the actual request payload and the meaning of the counted statuses unspecified. An agent can call it, but only after a second schema lookup.

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 0% on an opaque 'arguments' object, so the description would need to compensate. It does point the agent to get_cn_data_tool_schema('v3_trademark_status_count') and names company_id as a required input, but gives no format, allowed values, or optional filters, so half the burden remains.

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 opening line '查询各商标状态数量' states a specific verb (count) and resource (trademark statuses), which is enough to distinguish it from siblings like cn_data_v3_trademark_type_count or cn_data_v3_trademark_apply_trend. It is clear but does not explicitly contrast itself with those nearest siblings, and 'status' is left undefined.

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 gives one real prerequisite — 'Use company_id from cn_data_v3_company_detail' — plus the pagination rule that additional pages need separate requests. However, it never says when to choose this over cn_data_v3_trademark_type_count, cn_data_v3_trademark_register_trend, or the other trademark siblings, leaving selection to inference.

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 no annotations, the description carries the full burden and does substantial work: it discloses a single returned array, that history is not guaranteed complete, that counts/trends/headers are not underlying records, that additional pages require separate requests, and a per-call cost of 0.011 USDC. These are genuine behavioral facts beyond the schema, though they are boilerplate-heavy and repeat the 'no completeness/safety guarantee' caveat.

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 actual purpose is front-loaded in one short sentence, but it is then buried under boilerplate that repeats itself — 'No independent entity identity, freshness, completeness... safety certification' and 'No completeness or safety guarantee' say the same thing twice. Mixed-language disclaimers dilute signal and waste space.

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 tool with no output schema and an opaque argument object, the description covers purpose, cost, pagination, and reliability caveats, and hints at return shape ('one returned array'). It still omits what the returned fields actually look like and leaves the argument structure entirely to an external schema lookup.

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 0% and the only parameter is an open 'arguments' object, so the schema contributes nothing. The description partially compensates by naming company_id as an input and by pointing the agent to get_cn_data_tool_schema("v3_trademark_type_count") for the full argument contract, but this is an indirect deferral rather than direct parameter documentation.

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 opening sentence '查询商标国际分类分布' states a specific verb and resource (trademark international classification distribution), which is clear and actionable. However, it never differentiates itself from the many closely named siblings such as cn_data_v3_trademark_status_count, cn_data_v3_trademark_apply_trend, or cn_data_v3_intellectual_count, leaving the agent to infer the boundary.

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 supplies one concrete prerequisite: 'Use company_id from cn_data_v3_company_detail', which tells the agent where the key input originates. It gives no when-to-use/when-not guidance and no comparison against the other trademark and intellectual-property count 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: nulls mean unknown, a summary/header is not the underlying record list, no freshness/completeness/ownership/safety guarantees, per-call pricing, and paginated access requiring separate requests. It omits auth/permission needs, but for a read-only data query the disclaimers are substantive.

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 purpose is front-loaded in the first clause, which is good. However, the body mixes Chinese and English and repeats the same caveats – 'no completeness... certification' near the start is echoed by 'No completeness or safety guarantee' at the end – so several sentences do not fully earn their place.

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 no output schema, an opaque parameter, and no annotations, the description covers cost, pagination, null semantics and the ID prerequisite, which is reasonably complete. It stops short of specifying the argument fields or what the count breakdown contains, delegating that to get_cn_data_tool_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?

Schema coverage is 0% and the single parameter is an opaque free-form object (additionalProperties: true). The description partially compensates by naming the expected input (company_id from company_detail) and pointing to get_cn_data_tool_schema for the argument shape, but it does not define the parameter format itself.

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 names a specific verb and resource: querying the count of a company's website filing (备案) and IP information. It is clearly a count/summary tool, which implicitly separates it from the list-style siblings like cn_data_v3_website_ip and cn_data_v3_website_record, though it never explicitly says so.

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 states the prerequisite that company_id must come from cn_data_v3_company_detail and that additional pages need separate requests, which is useful routing context. However, it gives no explicit guidance on when to choose this count tool over the sibling website tools (website_ip, website_record, website_seo, etc.).

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?

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?

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?

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?

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?

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 no annotations, the description carries the full burden. It does disclose per-call pricing (0.011 USDC), the single-call limit, separate-request pagination, null-means-unknown semantics and explicit no-guarantee disclaimers. But much of this is generic boilerplate reused across the family and it says nothing about authentication or error behavior, so it is adequate rather than 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 purpose is front-loaded, but the body is a fragmented, partly duplicated bilingual block of boilerplate disclaimers with no clear ordering. It is not bloated, yet several sentences restate the same no-guarantee idea.

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 data-fetch tool with no annotations and no output schema, the description covers the essentials an agent needs to invoke it: cost, one-call scope, pagination behavior, null handling and a schema pointer. It omits any sense of what the returned module data contains, which with 68 siblings would have helped disambiguation.

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 0% and the only property is an open nested 'arguments' object, so the schema explains nothing. The description partially compensates by pointing to get_cn_data_tool_schema("v3_website_modules") for argument format and identifying company_id as a needed input, but it does not enumerate required fields itself.

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 Chinese clause gives a specific verb+resource: identify website customer-service, registration/login and other functional modules. That clearly separates it from website_count/website_ip/website_seo/website_tech siblings by naming the module-identification angle. It stops short of explicitly contrasting the closest alternatives, which keeps it out of the top band.

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 states a prerequisite (use company_id from cn_data_v3_company_detail) and a scoping rule (one selected company tool call; additional pages require separate requests). However, it never says when to prefer this over website_tech/website_seo or when-not to use it, so usage is only implied.

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 no annotations, the description fully carries behavioral disclosure: row limit ('at most 5 rows'), no pagination input, cost per call (0.011 USDC), disclaimers about lack of independent verification and safety guarantees, and a note that only empty page semantics were validated. This is unusually rich and 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?

Purpose is front-loaded, but the description runs long and repeats disclaimers (e.g., 'no completeness or safety guarantee' appears in different forms). It reads as a stream of caveats rather than a tightly structured definition.

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?

Covers usage context, cost, page limits, trust caveats, and points to a schema-discovery tool for argument structure. No output schema exists, so return-value details are not required. The main gap is the lack of direct parameter documentation, but the external schema pointer partially compensates.

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 0% and the single 'arguments' parameter is an opaque object. The description only mentions 'company_id' and defers to get_cn_data_tool_schema('v3_website_record') for full arguments, providing minimal direct semantic guidance about what keys to pass or their formats.

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 first sentence names specific fields the tool returns: '查询网站名称、域名、备案号与许可证' (website name, domain, filing number, license). This distinguishes it from generic website siblings like website_count or website_seo, though it does not explicitly compare itself to those 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?

States clear context: 'Use company_id from cn_data_v3_company_detail' and 'One selected Chinese company data tool call.' It also notes pagination behavior ('Additional pages require separate requests'). It lacks explicit when-not-to-use or direct sibling comparisons, but the provided context is 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?

With no annotations, the description carries the full burden and does disclose some real traits: per-call cost (0.011 USDC), that null means unknown, that a summary/header is not the underlying record list, and that pagination needs separate requests. Much of the remainder is generic legal boilerplate ('No independent entity identity, freshness, completeness...') that adds little invocation-relevant context, and nothing is said about auth or error behavior.

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 purpose is correctly front-loaded in the first sentence. The rest is a repetitive block of disclaimers where ideas recur ('No completeness or safety guarantee' and 'No ... completeness ... certification' overlap), so several sentences do not earn their place.

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 complex data tool with no output schema, no annotations, and a nested free-form parameter, the description does route the agent to a schema tool and to company_detail for the key input. It still omits what the SEO response actually contains and how to interpret 'website weight' versus 'indexing', so it is only minimally 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 coverage is 0% and the single parameter is an opaque free-form 'arguments' object, so the description must compensate. It partially does by pointing to get_cn_data_tool_schema("v3_website_seo") and naming company_id, but it never enumerates the actual SEO fields or their formats, leaving the required payload largely undiscoverable from this definition alone.

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 opening line names a specific verb and resource in Chinese: query website weight, indexing, and SEO metrics. This is clear and distinguishable as an SEO-metric tool. It does not, however, differentiate itself from the many website siblings (website_count, website_ip, website_record, website_tech, website_modules), leaving the agent to guess when SEO specifically applies.

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 supplies a prerequisite ('Use company_id from cn_data_v3_company_detail') and notes that additional pages require separate requests, which is helpful. However, there is no guidance on when to choose this tool over the other website tools, nor any exclusion criteria. Usage context is implied at best.

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 no annotations present, the description carries the full burden and does disclose real behavioral traits: null means unknown, a summary/header is not the full record list, pagination needs separate requests, cost is 0.011 USDC per call, and there is no completeness/safety guarantee. It lacks any auth/permission detail and does not describe the actual return structure, keeping it below a 5.

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 purpose is front-loaded and readable, but the body mixes Chinese and English and piles on boilerplate disclaimers (no completeness, safety, ownership, compliance certifications) that consume space without aiding selection or invocation.

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 a nested, undocumented argument object and no output schema, the description gives useful behavioral caveats and routes the agent to the schema tool, but the absence of concrete argument fields and any return-shape hint leaves an agent reliant on an external call to invoke 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?

Schema coverage is 0% and the single parameter is an opaque 'arguments' object with additionalProperties=true and nesting, so the schema alone conveys nothing. The description partially compensates by naming company_id and deferring to get_cn_data_tool_schema, but it never enumerates or explains the real fields, so semantics remain thin.

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?

States a clear verb+resource: '查询网站技术、域名年龄与标准指标' (query website technology, domain age, and standard metrics), which is specific enough to know the domain. However, it does not differentiate itself from the many adjacent website siblings such as cn_data_v3_website_seo, cn_data_v3_website_modules, and cn_data_v3_website_record, leaving overlap ambiguity.

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 the prerequisite data source ('Use company_id from cn_data_v3_company_detail') and points to get_cn_data_tool_schema for argument shape, plus notes that additional pages require separate requests. It stops short of saying when to pick this over the other website_* tools, so usage is only implied.

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 no annotations, the description carries the full burden and does so fairly well: it discloses provider first-page-only behavior, a 5-row cap, no pagination input, unknown total coverage, that empty results are not a safety finding, and a per-call price of 0.011 USDC. It omits return format and any permission/auth requirements, keeping it short of a 5.

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?

Purpose is front-loaded, but the body mixes useful operational facts (rows, pricing, pagination) with repetitive disclaimer text ('No completeness or safety guarantee' overlaps with the preceding certification disclaimer). Some sentences could be merged without losing meaning.

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 read-only query tool with no output schema and no annotations, the description supplies the essential operational context: input source, row limit, pagination constraint, cost, and coverage caveats. What remains missing (return fields, auth needs) is minor given the tool's nature.

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 0% and the single parameter is a generic untyped 'arguments' object. The description partially compensates by pointing to get_cn_data_tool_schema("v3_wechat") for the real argument shape and naming company_id as the key input, but it leaves the remaining parameter structure undocumented.

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 opening sentence '查询企业微信公众号信息' states a specific verb (query) and resource (enterprise WeChat official account info). However, it does not distinguish this tool from adjacent siblings such as cn_data_v3_media_count or cn_data_v3_sina, which also cover a company's media/social footprint. Clear but not sibling-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?

It gives an input-sourcing instruction ('Use company_id from cn_data_v3_company_detail') and notes the 5-row / no-pagination behavior, which implies the retrieval context. But it never states when to choose this tool over alternatives or any exclusions. Usage 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?

With no annotations, the description carries the full burden and does so well: first page only, at most 5 rows, no pagination input, empty results are not a safety finding, the records do not establish ownership or a licence, per-call cost is stated, and no completeness/safety guarantee. This is strong behavioral disclosure, though it omits the returned field structure and any auth/permission notes.

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 resource is front-loaded, but the text is padded and repeats caveats ('does not independently attest entity identity or completeness' vs 'No completeness or safety guarantee'), and the cost sentence and schema-pointer sentence are interleaved with them. Several sentences restate the same disclaimers.

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 nested-argument tool with no output schema and no annotations, the description supplies the key context an agent needs: the required source of company_id, the 5-row page cap, the lack of attestation, and the cost. Only the return-field detail and argument-level semantics are left unaddressed.

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 0% and the only parameter is an opaque nested object with additionalProperties, so the schema explains nothing. The description partially compensates by naming the required company_id and directing the agent to get_cn_data_tool_schema("v3_work_list"), but it does not document the argument fields or formats itself.

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 names a specific resource ('Recorded copyright works') and its provider context, and points to cn_data_v3_company_detail for the required company_id. It is clear what the tool returns, though it does not explicitly distinguish itself from nearby siblings like cn_data_v3_software_list or cn_data_v3_intellectual_count.

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 states a prerequisite (requires the Jinghai company_id from cn_data_v3_company_detail) and notes additional pages need separate requests, which implies single-page usage. However, it gives no explicit when-to-use vs when-not guidance or routing against the many similar cn_data_v3_* list 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 mark this as non-read-only, non-idempotent and destructive; the description adds crucial operational context beyond that: x402 v2 wallet client requirement, explicit spending approval, saved X-CN-Recovery-Token header, no automatic tier upgrade or retry, and that provider content is untrusted evidence. This is a paid, irreversible spend, and the description discloses the payment, recovery and trust model 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?

Dense but front-loaded: what it is, then options, payment requirements, failure handling and trust caveat. The final 'untrusted evidence' clause is slightly abrupt and the sentence about no retry/upgrade could be grouped better, but nothing is wasted.

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 paid, destructive, open-world tool with no output schema and 0% schema coverage, the description covers the critical gaps: payment protocol, recovery path, tier selection and trust boundary. It doesn't explain the report's output shape, but with an explicitly contracted deliverable that is acceptable; a brief line on what the report contains would complete it.

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 0%, so the description must carry the burden. It explains plan comes from get_china_report_options, that contract must be pinned, and max_price_usdc is a spending cap, which is meaningful beyond the bare field names. It does not describe company_name beyond its obvious meaning, hence a 4 rather than 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?

States a specific verb and resource: buying one contracted China company screening report with structured findings, sources, gaps and coverage. It explicitly disclaims what it is not ('not a guarantee of complete due diligence'), which distinguishes it from the many sibling cn_data_v3 read tools and from the supplier evidence 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?

Gives explicit routing: choose standard/enhanced/resilient from get_china_report_options, and on any signed failure use the free recovery path (recover_china_company_report) rather than repaying. When-to-use and when-not-to-use are both covered.

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 already declare readOnly, idempotent, non-destructive and closed-world behavior, so the burden is light. The description adds genuinely new behavioral context: it is free and performs neither a provider query nor a payment, which tells an agent this call has no cost or external side effect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.