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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety and repeatability are covered. The description adds that validation is "deterministic structure validation" and that results come back as a "receipt," but it never says what happens on malformed input, or how an all-optional empty call behaves. The deterministic-structure claim sits slightly awkwardly against openWorldHint=true without clarifying whether any external lookup occurs.

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 short sentences, with the composite scope front-loaded ahead of the validation claim. Little waste, though "scope stated per identifier" is vague filler that does not earn 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?

An output schema exists, so return values needn't be explained, and all three optional parameters are fully documented. What is missing is the meaning of "verification" here — checksum/check-digit validation versus registry lookup — and behavior when no identifiers are supplied, which is a real gap given required=[].

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% — each of trn, iban and swift has a description plus a worked example, so the schema carries the parameter burden. The description contributes only the informal labels (UAE TRN, settlement IBAN, SWIFT/BIC) and adds no format or validation-rule detail beyond what the schema already states.

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?

"One call, one receipt: UAE TRN + settlement IBAN + SWIFT/BIC" states a concrete composite resource and makes clear this bundles three identifier checks rather than one. That distinguishes it in substance from uae_trn_check, iban_check and swift_bic_check, though those siblings are never named and the closing phrase "scope stated per identifier" is opaque.

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?

"Gulf trade corridors" implies a supplier-onboarding context, but there is no explicit when-to-use statement and no routing versus the three single-identifier sibling tools that do the same work individually. An agent must infer that this is the bundled alternative, and nothing says when a single check is preferable.

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