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

With no annotations, the description carries the burden and does add real context: it is a lookup against an external API, sourced under CC0, with provenance attached, and it names the returned fields. It does not cover not-found behavior, rate limits, authentication, or whether a name search can return multiple candidates.

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?

Two tight sentences: capability and access modes first, return payload second, provenance last. Every clause adds information and nothing is repeated from the schema.

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?

There is no output schema, so the description usefully enumerates the return fields and notes provenance/licensing. The remaining gap is the invocation constraint (zero required params, so presumably at least one of lei/name must be supplied) and multi-result behavior on name search.

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% (both params documented, including the 20-character LEI constraint), so the schema does the heavy lifting. The description's 'by LEI or by name' hints that the params are alternative lookup keys, but it never says whether both may be supplied or which wins — a meaningful gap the schema leaves open.

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 states a specific verb and resource: resolve a legal entity to its LEI via the GLEIF API, with both lookup modes named. It is clearly distinct from screening tools like sanctions_screen or pep_screen, though it does not explicitly distinguish itself from cross_registry_resolve or entity_match.

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?

'By LEI or by name' implies two usage modes but never states when to prefer one over the other, nor when to reach for a sibling like entity_match or cross_registry_resolve instead. Usage is inferable from the tool's purpose but no alternatives or exclusions are given.

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