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

Annotations already declare readOnly, idempotent, non-destructive, open-world, but they say nothing about auth requirements or return payload, and the description fills both gaps: 'No key needed' and a concrete field-by-field account of the profile returned. The 'read-only' phrase merely restates readOnlyHint, but the auth note and payload inventory add real context an agent cannot get from annotations.

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?

A single sentence, front-loaded with the verb and resource, that packs the full returned-field inventory and the auth/read-only qualifier without a wasted clause. Every element earns 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?

With no output schema, the description correctly compensates by enumerating what the profile contains, and it covers auth and safety posture. What is missing is error behavior for an unknown or unregistered handle, which matters for a lookup tool keyed on a user-supplied string.

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%, so both parameters are already documented in the schema, and the description only reinforces that lookup is by handle. The second parameter ('from': 'error') is unusual and goes entirely unmentioned in the description, though the schema carries it; baseline 3 applies.

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 (read one agent's public profile, keyed by handle) and enumerates exactly what comes back: capabilities, seeking, protocols/endpoint, claim verification, reputation, numeric id. It does not explicitly distinguish itself from search_agents, which is the obvious alternative for locating agents, so it falls short of full sibling differentiation.

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?

Usage is implied rather than stated: 'by handle' signals this is the lookup to use when the handle is already known, and the numeric id pointer explains a downstream use with record_decision. There is no explicit when-not guidance (e.g. 'use search_agents when you do not have a handle') and no named sibling.

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