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

Goes well beyond readOnlyHint/openWorldHint by disclosing the AppView index dependency, possible missing accounts, and the critical caveat that results are search candidates rather than verified handle-to-DID mappings. These are non-obvious behavioral traits that affect trust decisions.

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 sentences, front-loaded with the action and scope, followed by return semantics, then the crucial verification warning. Every clause earns its place; there is no filler.

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?

Given an output schema exists, the description need not explain returns in detail, but it still clarifies candidate semantics and verification needs. Combined with annotations and schema, an agent has everything needed to call and correctly interpret the tool.

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%, so the schema already fully documents query, limit, and cursor. The description only restates that search is by handle or display name and is paginated, adding no syntax or format detail beyond the structured fields.

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?

States a specific verb and resource ('Search for AT Protocol accounts by handle or display name'), names the underlying data source, and describes the return shape and core use case. It clearly distinguishes this discovery tool from sibling verification/resolution tools.

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?

Explicitly tells the agent when to use this tool and, more importantly, when not to trust its output: 'call verify_handle before trusting that a handle really belongs to a DID', and explains why resolve/get_profile are insufficient for authenticity. This is direct routing guidance against specific siblings.

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