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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral depth: it never fabricates results, returns an honest not_found with the queried sources, and reveals cost and latency. This strongly informs an agent about side effects and reliability expectations.

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 longer than average but organized into labeled sections (WHEN TO USE, WHEN NOT TO USE, COST, LATENCY) and front-loaded with the core purpose. The example queries are valuable. Minor redundancy exists between the opening 'Free' and the COST line, but overall every section 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 3-parameter tool with no output schema, the description is complete: it states the data sources, return fields, not_found behavior, usage boundaries, cost, and latency. An agent has enough context to select this tool correctly and interpret the response even without an 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?

Input schema already covers all three parameters with descriptions, so baseline is 3. The description adds relational meaning: name is required and can be paired with an optional country filter, while LEI enables a direct precise lookup. The example user queries map natural-language utterances to concrete parameter combinations, which exceeds schema-only information.

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 verb+resource: 'Free, live lookup of a company official registry record.' It names the data sources (GLEIF, SEC EDGAR), the exact fields returned, and the not_found behavior, so an agent can clearly distinguish it from a generic search or a sanctions screen. The example queries further reinforce the intended scope.

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 explicit WHEN TO USE scenarios (contract signing, vendor qualification, counterparty validation) and WHEN NOT TO USE exclusions (private companies not in GLEIF/SEC, exhaustive fraud detection). It does not name an alternative sibling tool like screen_sanctions, so it stops short of full alternative routing, but the guidance is clear and actionable.

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