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

With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral trait: the response is private and secret-bearing, so it must not be shared. It still omits what happens on a bad secret, whether reads are rate limited or logged, and whether the projection is deterministic.

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 short sentences, front-loaded with the action and ending with the most operationally important warning. Dense but free of 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?

A 2-required-parameter tool with no output schema, no annotations, and half its parameters undocumented needs far more: what the projection contains, what errors look like, and what submission_id refers to. The security warning is the only genuinely complete element.

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 only 50%: agent_secret is documented but submission_id has no description anywhere. The phrase "your secret" loosely maps to agent_secret but adds nothing beyond the schema pattern, and submission_id is left entirely unexplained.

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?

Names a verb ("Recover") and a scope ("your own"), which distinguishes it somewhat from the read_* siblings that fetch shared content. However, the objects of the verb — "encrypted projection" and "private blind" — are opaque project jargon that does not tell an agent what data actually comes back.

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?

No statement of when to use this versus read_feed, read_guidance, or check_status. The only guidance is a security warning about not sharing output, which is a constraint rather than a usage condition.

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