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

Annotations only say not-read-only and not-destructive, but the description adds the operationally critical facts: the link needs no sign-in, lives 7 days, anyone holding it can pick, picks never purchase anything, there is a 20-links-per-day cap, and behavior differs in MCP Apps chats versus plain chats. These are exactly the side-effect and limit disclosures an agent needs before invoking.

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?

Front-loaded with the purpose, then the link mechanics, curation guidance, and the safety/confirmation rule in a logical order with no filler sentences. It is a dense multi-idea paragraph, which slightly reduces scannability but 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 four-parameter tool with no output schema, the description covers authentication (header vs. embedded token vs. MCP app sign-in), rate limits, result retrieval path, and the never-auto-purchase safety rule. Nothing needed to call it correctly is missing.

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%, so the schema already documents all four parameters including token format, inbox routing, and note constraints. The description reinforces the items/note usage ('up to 12 items you recommend first, with a short note... no links') but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb and resource ('Show your human what AgentMart sells, as cards... let them pick') and names the concrete artifact it produces (a pick link). It is clearly distinguishable from sibling tools like get_owner_picks, save_owner_picks, and search_catalog, which occupy the read/save/browse roles in the same flow.

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 routes the agent through the full loop: curate up to 12 recommended items, read the result with get_owner_picks, and confirm with the human via buy only after confirmation. That gives clear context for when to call this and what to do next, though it lacks an explicit statement of when *not* to use it or a direct contrast with save_owner_picks.

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