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

Annotations carry only openWorldHint, so the description carries the behavioral disclosure burden — and does so well by enumerating covered indicators (新增数量/占比、注销吊销、近2年增长、存续年限结构), exclusions, and even the per-data-unit pricing/billing model. It loses a point for not addressing edge behaviors like what happens on mismatches or empty returns in the main text (version semantics live only in 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 functional description is tight — a single sentence each for purpose, exclusions, and typical questions. The appended pricing JSON is verbose but earns its place by disclosing metering costs upfront, which directly affects whether an agent chooses this paid tool. Minor deduction for the pricing block being somewhat bulky for what could be EMBEDDED more compactly, 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 moderately complex tool (3 params, 1 required, output schema present, no nested objects), the description covers the essential ground: what indicators are included, what's excluded, example queries, and cost structure. The versioning nuance is handled in the schema. The only thing one might ask for is more on the output/return shape, but the presence of an output schema lowers that burden. Complete for practical agent use.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the schema already documents param behaviors richly (version_mismatch, per-query-type gov_names semantics, input_text extraction fallback). The description adds value by enumerating the indicator dimensions (survival-years structure, 2-year growth) that inform how a user would phrase input_text, and the pricing unit description clarifies the region × indicator × date version cost model. This is slightly above baseline but the schema still carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource+scope: '查询地区企业/个体户新增注册、注销、吊销与增长等异动指标', precisely identifying what metrics are covered. It also explicitly carves out 存量规模点查 via '不含存量规模点查主口径（请用市场主体规模）', distinguishing it from the sibling gov_data_enterprise_scale. This clearly positions the tool within the gov_data family.

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 explicitly names the alternative for scale queries ('请用市场主体规模'), giving a clear when-NOT-to-use signal and redirecting to the sibling tool. It further grounds usage with typical question patterns ('某区本年度新增注册企业数量、新增企业最多的城市'), which is exactly the 'when to use' guidance needed.

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