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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuine behavioral context beyond that: whether the returned price is exact depends on supplying a street address versus falling back to the shop's typical fee, and the lookup is scoped to one bouquet per call.

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 sentences, with the usage trigger front-loaded and the returned fields following. The long parenthetical about delivery_fee_exact is slightly convoluted but every clause carries information; nothing is padding.

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?

An output schema exists, so return structure need not be spelled out, and the description still summarizes what comes back. Combined with the annotations and near-complete parameter descriptions, an agent has enough to invoke the tool correctly; only explicit alternative routing 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 coverage is 80%, so the schema already documents date, where, locale and fulfilment formats. The description nonetheless adds meaning by tying the 'where' parameter to price precision (exact fee for a street address, typical fee otherwise) and by noting bouquet_id must be the value as shown in search results.

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 states a specific verb and resource (fetch one bouquet's details from search results) and enumerates the returned content: contents, size, photos, florist rating, price with delivery, and arrival times. 'Covers one bouquet at a time' cleanly distinguishes it from the bulk-oriented pinflower_search_bouquets sibling.

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 opening clause gives a clear trigger: 'Use this when the buyer is interested in one bouquet from the search results.' It implicitly routes the agent from search to detail and notes the single-bouquet scope, but never explicitly names the alternative to use for multiple bouquets or when not to call it.

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