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

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

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

Is the description appropriately sized, front-loaded, and free of redundancy?

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

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

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

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

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

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

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

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

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

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

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