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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does: 'Pouncio judges from its own data and does not open the page, so pass the asking price if the person mentions it' explains the non-fetching behavior and its consequence. It also discloses which data sources the verdict draws on (resale model price, seller record when known). It stops short of describing the shape of the verdict itself.

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?

Three sentences, each doing distinct work: trigger, internal behavior/rationale, exclusion with fallback. The usage condition is front-loaded and there is no filler or restatement of the tool name.

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 still conveys enough: it states what is compared (price vs. resale model, seller record) and that judgment comes from internal data, so the agent knows what kind of verdict to expect. Only the concrete verdict structure is left implicit, which is a minor gap for a read-only lookup 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 100%, so baseline is 3; the description earns a bump by explaining why asking_price matters — because the tool does not open the page, the price must be passed explicitly if the user mentioned it. That is a semantic rationale the schema field text ('The listing's price, if the person said it') does not convey on its own.

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 names a specific verb and resource — evaluating a shared Vinted listing link for deal quality, resale value, or scam risk — and the scope is immediately distinguishable from siblings like check_resale_price and check_listing_text. An agent knows exactly what question this tool answers.

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 gives an explicit trigger ('when someone shares a Vinted listing link and asks whether it's a good deal, worth buying to resell, overpriced, or a scam') plus an explicit exclusion and the alternative to use instead ('Do not use without a Vinted link (use check_resale_price)'). Both use and non-use conditions are stated, not inferred.

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