is_favourite

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

No annotations are supplied, so the description carries the full behavioral burden; it does disclose the authentication requirement, which is the single most important operational fact. It does not state that the call is a non-mutating status check, nor does it describe error behavior for guests or missing products. Given the output schema exists, return-shape details are not expected here.

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 no filler, and the core purpose is front-loaded ahead of the login constraint. The first sentence is a fragment rather than a complete statement, which slightly weakens clarity for no length savings.

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?

This is a low-complexity single-parameter status check with an output schema, so the description need not explain return values. Purpose plus the login prerequisite covers most of what an agent needs; only the identifier format and behavior for invalid inputs remain unstated, which are minor for this complexity level.

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?

There is one required parameter with 0% schema description coverage, so the description should compensate but largely does not. The phrase 'a product' loosely ties to product_id, and the parameter name is self-explanatory, but the description adds no detail on whether the identifier is a numeric ID, slug, or SKU, nor whether the product must exist.

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 the specific resource (a product) and the specific predicate being evaluated (favourite status), so an agent can distinguish it from siblings like favourites, add_favourite, and remove_favourite. It is phrased as a fragment ('Whether a product is a favourite') rather than an explicit verb, but the meaning 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?

The prerequisite 'Requires login' gives the agent a gating condition, which is genuinely useful. However, there is no guidance on when to call this versus favourites (the list) or add_favourite/remove_favourite, and no mention of behavior for unknown or invalid product IDs.

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