Pinflower — flowers in Prague

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

The annotations already mark the tool as destructive and non-read-only, and the description reinforces and expands on that by explaining the two-step confirmation flow, the emailed 6-digit code, refund behavior, and time-window rules. This adds meaningful context beyond the annotations and contradicts none of them.

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?

Every sentence serves a purpose: trigger condition, policy rules, step-by-step procedure, and exclusion of order changes. The content is dense but well organized and front-loaded with the most important usage signal.

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?

The description fully covers when to use the tool, the ordered invocation steps, the policy constraints, and the key exclusion. With an output schema present and annotations covering safety, nothing necessary for an agent to call this tool 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?

Although schema description coverage is 67%, the description explains how order_ref, confirm, and code are used across the two calls, including which parameters belong to the first versus second invocation. This adds substantial meaning beyond the raw 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 action (cancel an order) with a clear trigger condition (buyer explicitly asks) and ties it to the related create-order tool. It also explicitly distinguishes itself from order modification, making it easy for an agent to select correctly among the sibling tools.

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?

Provides explicit when-to-use guidance: only when the buyer asks to cancel, and not for changing an order. It also details the cancellation rules and the exact two-step invocation flow, leaving no ambiguity about how to proceed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context about the scope of queries it handles (delivery feasibility, cost, timing), which goes beyond annotations. It doesn't describe return format, but an output schema exists, so this is adequate.

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?

The description is three sentences, front-loaded with the primary use case and ending with a clear exclusion. There is no wasted wording, and it reads naturally while being efficiently structured.

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?

Given the tool's simplicity (3 params, 1 required), existing output schema, and annotations covering safety, the description covers all necessary context: when to use, what it does, and when not to use. Nothing essential is missing for an agent to call it correctly.

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 parameters. The description adds one nuance: 'Pass the place as the buyer said it', reinforcing the 'where' parameter's semantics, but this is minor and doesn't significantly enhance understanding beyond 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?

The description clearly states the tool checks delivery to a place, answering whether delivery is available, cost, arrival time, and tonight availability. It explicitly distinguishes from bouquet search by saying it's not needed when already searching bouquets, and it ties usage to pre-bouquet selection, differentiating it from other siblings like quote or order tools.

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 provides explicit when-to-use conditions: when the buyer asks about delivery to a place, cost, timing, or tonight delivery before choosing a bouquet. It also gives a clear when-not-to-use: when already searching bouquets for that place, which directly references the sibling search_bouquets tool.

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

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

It discloses important side effects beyond sparse annotations: nothing is charged, the florist is not told until the buyer pays, a changed total creates nothing, and retrying with the same order_intent returns the same order. This is exactly the behavioral context an agent needs before invoking a checkout-creating tool.

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?

Though long, the description is dense and well organized: trigger, arguments, mismatch behavior, collection checklist, conditional requirement, and side-effect safety. Every sentence carries operational value for a 22-parameter tool.

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 complex purchase-creating tool with sparse annotations, the description covers when to call it, what to collect, how to confirm the agreed total, what happens on mismatch, and what side effects occur. An output schema exists, so the return value does not need to be spelled out in prose.

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?

The description adds significant meaning beyond the schema: pass the same arguments as the quote, set terms_accepted=true, and set confirmed_total_czk to the agreed total. It also explains that a mismatch blocks creation, lists what to collect first, and calls out the conditional billing-address requirement over 10,000 Kč.

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 action with a clear resource: it creates the order like the website's checkout and returns the secure payment link on pinflower.cz. It also ties the tool to a precise precondition (agreement on the quote total), which distinguishes it from quote and search siblings.

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 trigger is explicit: use this when the buyer has agreed to the total from pinflower_quote_order. It gives collection steps and the total-change fallback, but does not explicitly name alternatives or state 'do not use before quoting'; the when-to-use is clear, but exclusion guidance is mostly implied.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds useful behavioral context beyond that: it computes exact delivery prices and all arrival slots for a given day, and depends on a prior search result. No contradiction with annotations.

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?

The description is compact and front-loaded with the primary use case, then the required input, then the key exclusion. Every sentence earns its place without redundancy or filler.

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?

Given the output schema exists and annotations cover read-only/idempotent behavior, the description completes the picture: trigger condition, prerequisite, scope, and what results to expect. Nothing essential is missing for correct invocation.

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 baseline is 3. The description adds extra meaning by explaining that bouquet_id comes specifically from a search and by linking the date parameter to arrival-time and delivery-price computation, which is not fully captured in 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?

The description names a specific verb and resource: getting details for one bouquet selected from pinflower_search_bouquets. It also enumerates the returned content — contents, size, photos, florist rating, exact delivery price, and arrival times — and explicitly contrasts with the search sibling for comparing many bouquets.

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 states exactly when to use this tool ('when the buyer is interested in one bouquet'), the prerequisite ('Needs bouquet_id from a search'), and the exclusion ('Not for comparing many bouquets — search does that'). This gives the agent clear routing guidance versus its siblings.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile. The description reinforces 'It changes nothing' (redundant) but adds the prerequisite that order_ref must come from pinflower_create_order, which is useful context beyond annotations.

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, front-loaded with the use case, then the prerequisite and exclusions. No filler or repetition.

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 simple read-only status tool with an output schema present, the description covers purpose, required parameter, and differentiation from siblings. Nothing an agent needs 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 50% (locale documented, order_ref not). The description compensates for order_ref by explaining its origin ('the order_ref that pinflower_create_order returned'), which is essential. It doesn't add extra detail for locale, but the schema already covers it.

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 clear, specific purpose: checking the status of an order (paid, confirmed, on the way, delivered) and ties it to a prior creation step. It explicitly names alternatives (pinflower_new_pay_link, pinflower_cancel_order) that it is not, distinguishing it from siblings.

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 a direct when-to-use condition ('when the buyer asks what is happening with an order'), requires a specific prerequisite (order_ref from pinflower_create_order), and explicitly lists exclusions for two other tools. This is clear, actionable guidance.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds valuable behavioral detail beyond that: it returns the same link while the order is open and never issues a second payable link. This clarifies side-effect expectations well, though it does not discuss potential edge cases like what happens when a link is truly expired.

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 convey the trigger condition, the result, the key behavioral constraint, the required parameter, and an exclusion. Every clause earns its place and the most important guidance is front-loaded.

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 single-parameter tool with an output schema, the description fully covers when to call it, what it returns, and what it avoids doing. The only slight gap is order_ref provenance, but the sibling context and output schema make this tool sufficiently self-contained.

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 0%, so the description must compensate. It does say 'Needs the order_ref' and implies it identifies the order, but it does not explain the format, origin, or how the agent should obtain a valid order_ref. The property name is self-explanatory, but the description adds only marginal semantic value beyond 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?

The description states a specific verb and resource: it returns the payable link for an order on pinflower.cz. It also distinguishes itself from pinflower_create_order by clarifying it does not create a second payable link, which makes the tool's purpose unmistakable.

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 explicitly says when to use it (buyer has not paid and the original link expired or got lost) and when not to use it (paid or cancelled orders). This gives clear routing guidance without needing to inspect sibling tools.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive; the description adds that it mirrors the checkout's final price (including launch discount or promo code and delivery fee) and validates the requested time. It also discloses that the call returns a breakdown with a terms link for the buyer, which is useful and not contradictory to the annotations.

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?

The description is front-loaded with trigger and behavior, then procedurally lists required information. It is dense but not padded; the only structural weakness is the long run-on collection checklist that would be easier to scan as bullets.

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?

Given the tool's complexity (18 parameters, nested objects, enums) and the existence of an output schema, the description is complete: it covers triggers, prerequisites, conditional requirements, next steps, and re-invocation. Minor unmentioned parameters like locale and unit are sufficiently documented in the schema.

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?

Even though the schema covers 72% of parameters, the description adds crucial semantics: items must be from ONE florist, address is 'street and house number in Prague,' address_mode='ask_recipient' is linked to a surprise and whole-city rate, recipient is required when someone else receives flowers, and billing_address is required above 10 000 Kč. It also prescribes the order and manner of collecting buyer, company, and promo-code data, effectively compensating for schema gaps.

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 specifies a concrete action ('prices the order exactly as the checkout will charge it'), names the resource (the order), and enumerates the pricing components (bouquets, add-ons, discounts/promo, delivery fee). It also differentiates from the sibling pinflower_create_order by stating 'without creating anything' and referring the buyer's 'yes' to that tool.

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 leads with an explicit trigger condition ('when the buyer has chosen what to order and you have the details') and lays out the information to collect before calling. It names pinflower_get_bouquet as the source for valid times and instructs to call pinflower_create_order with the same arguments after acceptance, and to 'Call it again after any change' – giving clear when-to-use and when-to-recall guidance.

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

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

Annotations already mark the call as read-only and idempotent, and the description adds a concrete behavioral contract: only bouquets that can actually arrive at the given place/time, with price, delivery fee, total, earliest delivery time, and the storefront's recommended order. No contradiction with annotations.

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?

The description is four purposeful, information-dense sentences with no filler. It front-loads the trigger condition and behavioral guarantee, then gives input guidance, exclusions, and next steps efficiently.

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?

Despite 17 parameters, the description plus 94% schema coverage and an output schema cover the full calling context: when to use it, what to pass, what results contain, and what to do next. Nothing essential for selecting and invoking the tool 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 94%, so the schema already documents the parameters well. The description adds useful guidance by telling the agent to pass the buyer's own words for free text, occasion, budget, where, date, and deliver-by time, plus an explicit result-count expectation of 3–6.

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 action — returning concrete, deliverable bouquets — and scopes it to Prague delivery/pickup. It clearly distinguishes the tool from general flower advice and from other tools like get_bouquet or store_info.

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 explicitly says when to use this tool (buyer wants flowers delivered/picked up in Prague and needs concrete bouquets) and when not to ('Do not use it for general flower advice or for orders outside Prague'). It also routes follow-up actions to pinflower_get_bouquet and pinflower_create_order.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context that answers come from the shop's own pages with links, which informs the agent about the response format and source. No contradiction with annotations.

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, front-loaded with the primary use case, then the exclusion. Zero filler, every clause earns its place.

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 read-only informational tool with a single well-documented parameter and an output schema, the description covers the key decision factors: when to invoke, what it returns (links from shop pages), and what it excludes. Nothing an agent needs 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%, with the locale parameter fully documented via enum and description. The description doesn't need to add param detail, and it doesn't – a baseline 3 is appropriate since schema carries the meaning.

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 ('use this when') and resource ('how ordering works'), and explicitly excludes bouquet availability, naming the alternative tool. It clearly distinguishes from siblings like pinflower_search_bouquets and pinflower_get_bouquet.

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 explicitly says when to use (buyer asks about ordering mechanics) and when not to use (bouquet availability), pointing to 'search'. This leaves no ambiguity about routing to the correct tool.

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