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

Adds substantial behavior beyond the annotations: explicit price ($0.25 per call), payment rail (USDC on Solana via x402), the two-step challenge/retry handshake, and an HTTP fallback URL. The word "Fetch" reads as a pure read, which sits in mild tension with readOnlyHint=false and idempotentHint=false, but paid-call metering plausibly explains that marking rather than contradicting it. It still does not state error behavior for unknown LEIs or whether a company with no group returns an empty tree.

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 sentences, front-loaded with what it returns, followed by the payment mechanics. The nested parenthetical is dense but every clause carries operational value (cost, rail, retry protocol, HTTP equivalent); nothing is filler, though it could be split for scanability.

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 is the only place an agent could learn what a "group tree" contains (parent, subsidiaries, consolidation, depth), and it says nothing about that shape or size. For a paid, non-idempotent call where a wasted invocation costs $0.25, omitting what the response looks like and what happens on no-match is a meaningful gap.

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 description coverage is 100% (the single lei parameter is documented as a 20-character ISO 17442 LEI), so baseline is 3. The description only echoes the parameter via the {lei} path segment and adds no format, normalization, or special-case meaning beyond the schema.

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?

Specific verb and resource ("Fetch a company's full GLEIF group tree") with the key domain qualifier GLEIF and the notion of a group/parent-child tree. It does not explicitly contrast itself with near-siblings like companies_enrich_profile, companies_enrich_financials, or companies_uk_ownership, so the agent must infer the distinction from names alone.

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 gives procedural guidance for how to invoke it (call unpaid to receive the PaymentRequired challenge, then retry with the payment at _meta["x402/payment"]), which is genuinely actionable. However, it gives no guidance on when to prefer this tool over its siblings or what input preconditions matter (e.g., needing a canonical LEI, or pointing to companies_enrich_resolve first).

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