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

The annotations only include openWorldHint (no safety annotations), so the description carries the full behavioral disclosure burden. It transparently lists what indicators are covered and what are not, and provides typical usage examples. However, it does not disclose any other behavioral traits such as data coverage limitations, historical depth, potential incomplete data (which openWorldHint might imply), rate limits, or error handling. Given the openWorldHint, one might expect a note about data completeness, but the description remains silent on that. It is transparent about scope but not about other behavioral nuances.

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

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

The description is well-structured: it opens with the core purpose, immediately follows with exclusions, then lists the specific indicators, and ends with typical examples. While it is somewhat long (due to the indicator list), every sentence earns its place by clarifying scope or usage. The indicator list is dense but necessary to convey the exact scope. It is not verbose or redundant; each part serves a distinct purpose. The front-loading of purpose and exclusions helps quick comprehension.

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

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

Given the tool's complexity (multiple indicators, open-world hint, and an output schema), the description covers the essential aspects: what it does, what it doesn't include, and how to invoke it with examples. The presence of an output schema means return value details are handled elsewhere, so the description need not explain them. It does not mention limitations like data coverage or historical range, but the openWorldHint is a structural annotation that might cover some of that. Overall, the description is complete enough for an agent to correctly select and invoke this tool for likely scenarios.

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

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

The input schema already provides 100% coverage with descriptions and examples for both parameters (company_name and country_name). The description reinforces this by giving typical questions that illustrate how the parameters are combined (e.g., '中国比亚迪股份有限公司'). It adds some contextual meaning by showing the expected format of the country name (both Chinese and English examples) but does not introduce any new parameter semantics beyond what the schema already states. Since the schema is fully self-explanatory, the description adds marginal value 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 clearly states that the tool queries periodic risk changes for enterprise key roles (legal representative, controlling shareholder, actual controller) with a specific verb (query) and resource (enterprise risk changes for these roles). It lists concrete indicators and explicitly distinguishes itself from other tools by stating what it is not for (enterprise's own violations like dishonest/restricted high consumption). This makes the purpose specific and distinct from sibling tools like enterprise_change_credit_debt_risk or enterprise_change_legal_compliance_risk.

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 guidance on when to use this tool: for querying background and litigation/execution risks of key roles. It also gives clear exclusions (not for the enterprise's own violation checks, not for batch screening by park/industry chain) and provides typical question examples. While it does not name alternative tools, the 'not included' section establishes boundaries, and the exclusions help differentiate from other enterprise_change_* tools. This is strong guidance, though not as explicit as naming a specific alternative.

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