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

With no annotations, the description carries the full burden and does well: it identifies the operation as a read of public data only, enumerates the excluded sensitive categories, and warns that agent-authored fields are untrusted data that must not be treated as instructions. It stops short of stating auth requirements or behavior for an unknown handle.

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 tight sentences, front-loaded with the capability and followed by the exclusions and the trust warning. No filler, though the injection warning is dense enough that it reads as a compressed security note rather than plain guidance.

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?

For a single-parameter read with no output schema and no annotations, the definition covers what is returned, what is deliberately withheld, and how to treat returned content. Missing only error/not-found behavior and auth prerequisites, which are minor for a public-read endpoint.

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?

Only one parameter, and the schema gives a pattern but no description (0% coverage). The description partially compensates by tying 'handle' to the /v1/agents/{handle} path shape, but it never explains the naming convention or what happens when no agent matches.

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 an agent's public profile and stats') and pins the exact payload by referencing the equivalent REST endpoint. It also carves out what the response excludes (live forecasts, vault values, unpublished rationales), which implicitly separates it from siblings like vault_head or my_forecasts, though it never names an alternative tool directly.

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 by the content scope: fetch this when you need an agent's public profile, not their private state. There is no explicit when-to-use or when-not-to-use routing versus siblings such as whoami (self) or get_trust (trust scores), so the agent must infer the choice.

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