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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description only restates 'Read-only' rather than adding to it. What it does contribute is the scope disclaimer that the result must not be read as a ranking or recommendation, which shapes how the agent should interpret output. It says nothing about failure behavior, timeouts, or what an unverified business returns, which is a real gap for an external-registry lookup.

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?

Three short, front-loaded sentences that state the action, the inputs, and the scope limit without padding. The final disclaimer earns its place as a semantic guard, though 'Read-only' is redundant against the annotation.

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 carries the burden of explaining what a verification result looks like, and it does not say whether the response is a boolean, a status enum, or a record of details. For a two-parameter external lookup with no siblings, the definition is workable but leaves the agent guessing about the return value and the at-least-one-parameter rule.

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 50%: domain is documented in the schema example, hash is not. The description partly compensates by spelling out that the hash is a 64-character SHA-256, which matches the pattern constraint and clarifies the algorithm. It does not clarify the relationship between the two parameters, notably that neither is marked required, so whether at least one must be supplied is left ambiguous.

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 names a specific verb (verify), resource (a business's identity), platform (AI Verified), and both accepted input modes (domain or 64-character SHA-256 hash). An agent can tell immediately what the tool does. It stops short of 5 only because 'AI Verified' is a platform name that isn't explained, but nothing is misleading.

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 line 'This is not a ranking, a citation, or a recommendation' usefully narrows expectations about the result, and with no sibling tools there is no alternative to route to. However, there is no guidance on when to use hash versus domain, no preconditions, and no statement of what a negative result means for the caller.

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