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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the write/idempotency profile is covered. The description adds genuine context beyond that: the call is human-triggered from in-chat cards and agents are forbidden from invoking it, which shapes agent behavior. It does not, however, say what happens to previously saved picks on a subsequent save.

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, with the scoping constraint and the human-trigger condition front-loaded before the agent prohibition and the pointer to the read alternative. Nothing is wasted.

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 three-parameter tool with full schema coverage and annotations covering safety and idempotency, the description supplies the missing pieces: who invokes it, when, and how to read the result. Only the mutation semantics of an existing picks list are left unstated.

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 description coverage is 100%, and the schema itself documents picks, chat_token and the ignored passport_token, so the baseline is 3. The description adds no parameter-level detail (e.g., replacement vs. merge semantics for the picks array) beyond what the schema already provides.

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 establishes that this tool exists for the AgentMart shop window flow and is fired when the human presses 'Send to my agent', which implies the recording of picks, and it explicitly names the sibling get_owner_picks as the read counterpart. The specific verb+resource ('save the owner's picks') is carried mainly by the title rather than the description text, so it is clear but slightly indirect.

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?

It states the exact condition under which it fires ('Only for the AgentMart shop window view... when your human presses Send to my agent'), an explicit prohibition ('Agents: never call it yourself'), and the correct alternative for reading ('read the picks with get_owner_picks'). When, when-not, and the alternative are all present.

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