Get Company AML Risk Score

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

Beyond the annotations (all false), the description discloses significant behavioral traits: it internally screens key persons and beneficial owners against PEP/sanctions, folds that into the score, generates an auditable report stored for 60 months, and may return asynchronously with a pending state. This is rich, safety-relevant context that the annotations do not 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?

The description is a single dense paragraph, but every sentence adds essential information: primary use, anti-pattern avoidance, backend report generation, async behavior, and polling. It is front-loaded with the core purpose and remains readable despite its length.

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

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

Given the complexity of the tool (async report generation, legal retention, interplay with sibling tools) and that an output schema exists, the description covers all the contextual ground needed. It addresses the likely edge case of pending results and directs the agent to the correct follow-up tool.

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

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

The input schema already fully documents both parameters (orgnr and purpose) with descriptions and an enum for purpose. The description only mentions 'by orgnr' and adds no additional parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool returns a structured COMPANY AML risk score (0-100) with a named level, keyed by orgnr. It explicitly identifies itself as the primary tool for 'what is the AML risk / AML score of company X', which differentiates it from siblings like check_aml_pep.

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 tells the agent exactly when to use this tool, instructs to call it ONCE per company, and explicitly says not to call check_aml_pep afterwards except for ad-hoc individual screening. It also provides guidance on what to do when the result is pending: poll get_aml_report with the rapport_id.

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