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

Annotations already cover mutability and idempotency (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description's job is to add context — and it does, disclosing the two-phase flow: a returned submission id stays pending until the maker clicks the emailed confirm link, which expires in 48 hours. It does not say what happens on a rejected/expired submission or whether resubmission is allowed, a minor gap.

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?

Purpose is front-loaded in the first sentence, followed by constraints then async behavior — a sensible ordering with no filler. The third sentence is densely packed (expiry, email, polling joined by a semicolon and parenthetical) and could be split for easier parsing.

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 takes on the return-value burden and does so, explaining that a submission id is returned and the record stays pending pending out-of-band confirmation. Combined with the verification/consent prerequisites, an agent has everything needed to call this correctly and know what to expect.

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% across 12 params, so the schema already carries parameter meaning and a baseline of 3 applies. The description only adds significance to makerEmail (it receives the confirm link), leaving the other 11 params to the schema.

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 ('Submit a product to Makeroo') plus the unusual acting-on-behalf-of scope ('on the maker's behalf'), which is not inferable from the name alone. The sibling set (get_listing, search_listings, get_submission_status, list_categories) is clearly a different kind of operation, and the description names get_submission_status as the follow-up, making the role 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?

Gives explicit preconditions — 'only submit what you verified from the product's repo or site' and 'only with the maker's go-ahead' — and names the alternative workflow step ('poll get_submission_status'). Both when-to-use and when-not-to-use constraints are present, which is rare.

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