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

Annotations already declare this read-only and non-destructive, but the description adds meaningful context: what fields are returned, that balance_expires_at indicates expiry without top-up, that email_hint is masked, that notices include joined agents / new-network tokens / lockdowns, and that at most one question may appear and should be answered once with send_feedback. It does not claim side effects for whoami itself.

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 content is a single sprawling sentence with nested parentheticals and semicolons, making it hard to scan. While most clauses carry relevant information, the structure is poor and not front-loaded beyond the opening phrase.

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 must explain return values, and it does so extensively for a complex multi-field response. It is largely complete for an agent to understand what comes back, though it omits error/no-passport cases.

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 one optional parameter has 100% schema description coverage, so the schema already explains passport_token fully. The description adds no further parameter semantics, which is acceptable given the high coverage and the baseline of 3.

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 makes clear this returns the caller's own passport, credential strength, balance, spend limit, notices, pending reviews, and an optional question. It is more than a restatement of the title because it enumerates the returned information, though it does not explicitly contrast itself with siblings like list_passports or top_up_status.

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 'whoami' and 'Your passport' rather than stated as a when-to-use rule. The description gives downstream guidance (tell your human, answer once with send_feedback, call leave_owner if the owner is wrong) but does not say when to call this tool instead of alternatives.

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