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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: the target parameter switches to an institutional projection, 'any other value falls through to the self-projection path,' and it notes special fields like 'honest-empty trait vector' and 'social_legibility.' This goes beyond the annotations without contradicting them.

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?

The description is three sentences, front-loaded with the primary purpose. Each sentence adds meaningful information: the base function, the optional target behavior, and the authentication note. It is a bit dense with technical specifics but avoids fluff, and all content 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?

For a tool with no output schema, the description does a good job explaining the return content (canonical handle, user summary, institutional projection fields). It covers authentication requirements, free institutional mode, and fallback behavior. It could be more explicit about the self-projection scope requirement (mentioned in schema but not description), but overall it is complete for the tool's complexity.

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?

The input schema has 100% coverage, already explaining that target 'today only ~alter is recognised' and any other value falls through to the self-projection path. The description repeats this and adds response details, but it does not add new parameter-specific semantics beyond the schema's own description, so the baseline score of 3 is appropriate.

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 clearly states that the tool 'Returns canonical handle and user summary for the authenticated member,' using a specific verb and resource. It distinguishes itself from sibling tools like alter_resolve_handle by focusing on the caller's own authenticated identity, and it details the optional target behavior for institutional projection.

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 description provides clear context on when to use institutional mode ('free for all callers') and how to authenticate ('mint a ~handle for free with register_autonomous_challenge then register_autonomous'). It implies the tool is for self-identity checks, but it does not explicitly name alternatives such as 'use alter_resolve_handle for resolving other handles,' so it lacks strong exclusions.

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