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

Annotations already declare readOnly/idempotent/non-destructive, so the description rightly focuses on what annotations cannot express: the returned markdown bundle is quoted untrusted data containing possible prompt injection, and the agent must not forward a model-provider key. That is genuinely useful behavioral context beyond the structured fields, though it says nothing about export size, limits, or failure modes.

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 action is front-loaded in the first sentence, which is good. However, the two near-identical 'quoted untrusted data' sentences are redundant and could be merged, and the string of imperatives crowds out the operational information an agent actually needs.

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 should describe the return value; it does at least name the markdown bundle format and its trust status. But it omits size/scope expectations, the effect of a missing api_key, and any sense of what the locker contains, leaving real gaps for a single-purpose export tool.

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 0% for the single api_key parameter, so the description must carry the burden. "This key's locker" only hints that api_key selects the locker; it never states the format, whether the parameter is optional (it is not required), or what happens when it is omitted.

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?

"Export this key's locker" gives a specific verb (export) and resource (locker) scoped by an API key, which distinguishes it from save_state/load_state/delete_state siblings. It stops short of saying explicitly what an export is versus a snapshot listing, but the core action is unambiguous.

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?

There is no guidance on when to export rather than call load_state, list_snapshots, or read_threads, even though those siblings overlap heavily with 'get data out of the server'. The description spends its words on security warnings instead of routing the agent, leaving selection to inference.

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