Pinflower — flowers in Prague

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

Annotations only flag destructiveHint/openWorldHint; the description adds the substantive behavior: a full refund of any paid amount, the two-step confirmation flow, and that a 6-digit code is sent to the e-mail the order was placed with. It also discloses the eligibility constraint that determines whether the cancel succeeds at all.

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?

Front-loaded with the trigger condition, then rules, then the two-step mechanism, then exclusions. Every sentence carries distinct information; there is no filler or restatement of the title.

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 an output schema present, return values need no explanation, and the description covers the remaining gaps: eligibility, refund outcome, the code-delivery step, and unsupported operations. An agent has everything needed to execute the two-call sequence 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 coverage is 67% (order_ref is undocumented there). The description compensates by explaining the sequencing semantics: order_ref + confirm=true issues the code, then order_ref + code completes the cancel. That flow meaning is not derivable from the schema alone, though it never describes the order_ref format.

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 ('cancel an order placed here') and immediately scopes the trigger to an explicit buyer request. None of the siblings (check_delivery, create_order, get_order_status, etc.) perform cancellation, so the agent can route unambiguously.

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 when-to-use ('buyer explicitly asks to cancel') plus eligibility windows (free until florist confirmation; later-day orders until the cut-off) and a when-not ('changing items, delivery details or the delivery time is not supported'). It stops short of naming which sibling to use for those unsupported changes, so the routing half is implicit rather than explicit.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered without help. The description usefully discloses the overlap with bouquet search results and that the place is taken verbatim, but says nothing about auth, rate limits, or failure behavior; an output schema exists so return format is not needed. This is modest added value over 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?

Front-loaded with the usage trigger, followed by two short supporting sentences; the total is appropriately sized for the tool's scope. The "Takes the place as the buyer said it" sentence is slight redundancy against the schema but cheap and reinforcing.

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?

Covers purpose, triggering questions, ordering relative to bouquet selection, and the overlap with search results, which is the main ambiguity an agent would face. Since an output schema exists, the lack of return-value detail is not a gap.

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 `where`, `date` and `locale`. The description's only parameter-relevant statement, "Takes the place as the buyer said it," repeats the schema's own wording rather than adding format or edge-case guidance. Baseline 3 is correct.

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?

Names a specific action (check delivery availability/cost/timing) for a specific resource (a place in Prague), and the phrasing "whether Pinflower delivers to a place in Prague, how much delivery costs, how soon it can arrive" enumerates the exact questions it answers. It also distinguishes itself from sibling pinflower_search_bouquets by noting search results already embed this data.

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 an explicit trigger ("Use this when the buyer asks whether...") plus a sequencing constraint ("before choosing a bouquet") and a de-duplication rule ("Bouquet search results already include this for their place"), which implicitly tells the agent not to call it redundantly. It stops short of naming the alternative tool explicitly or stating other when-not conditions.

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?

Adds substantial context beyond the annotations: 'Nothing is charged here and the florist is not told until the buyer pays' tempers the destructiveHint, and the order_intent explanation ('the same order_intent always returns the same order... safe to retry') independently confirms idempotentHint. It also surfaces the 10 000 Kč billing-address rule and the conditional recipient requirements for the ask_recipient / agree_with_recipient modes.

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?

Front-loaded with the purpose and trigger before the parameter walkthrough, and nearly every clause carries a real rule. However, it is delivered as one dense paragraph with a long 'Takes: ...' run-on, so it is harder to scan than it needs to be 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 22-parameter mutation with nested objects, the description covers the trigger, the no-op-on-total-change behavior, payment deferral, mode-specific requirements and threshold rules; an output schema exists, so return-value detail is correctly left out.

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 77%, but the description goes well beyond it by explaining cross-parameter business logic: several bouquets must be from ONE florist, recipient name+phone become required under ask_recipient and 'agree_with_recipient', billing_address is mandatory over 10 000 Kč unless buying as a company, and care_reminder is free and texted in Czech. This is meaning the schema alone does not convey.

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 — 'it creates the order exactly like the website's checkout and returns the secure payment link' — and its trigger condition ('when the buyer has agreed to the quoted total') cleanly separates it from the sibling quote_order and the read-only status/cancel 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?

Gives an explicit trigger ('when the buyer has agreed to the quoted total') and a when-not path (if the total changed, nothing is created and the new breakdown is returned), which tells the agent to re-quote rather than retry. It never names the sibling tools (quote_order, search_bouquets) directly, so routing still requires some inference.

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 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.

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

Annotations already cover read-only, non-destructive, idempotent and closed-world, so 'Read-only: it changes nothing' adds nothing. The real added value is the prerequisite disclosure that the order_ref comes from order creation, which tells the agent where to source the required input.

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 tight sentences: usage trigger first, prerequisite and safety second. The trailing 'Read-only: it changes nothing' is slightly redundant with the annotations but does little harm.

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 two-parameter read tool with an output schema and full annotation coverage, the description supplies the trigger, the input provenance and the safety profile. Nothing the agent needs before calling 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 only 50%: locale is documented in the schema, but order_ref is bare there. The description compensates by explaining that order_ref is the reference returned at order creation, which is meaningful provenance 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?

States a specific verb and resource ('get order status') and enumerates the states it reports (paid, confirmed, on the way, delivered), so the agent knows exactly what the call answers. It does not, however, differentiate itself from the sibling pinflower_check_delivery, which appears to overlap in scope.

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?

'Use this when the buyer asks what is happening with an order placed here' gives a clear trigger condition and a scope qualifier (orders placed here). No explicit when-not or sibling exclusion against check_delivery is provided, so it stops short of a 5.

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 flag this as non-read-only and destructive (destructiveHint=true), yet the description frames it purely as returning a link and never discloses what side effects or invalidation may occur — a real gap for a destructive tool. It does add useful behavioral context (idempotency in prose, the paid/cancelled guard) beyond the annotations, so it is not a contradiction, just incomplete.

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?

Front-loaded with the usage trigger followed by the return semantics and exclusion, delivered in a single dense sentence with no filler. The dash-clauses are slightly run-on but every clause carries information.

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 values need no explanation, and annotations carry the safety profile. However, for a destructive, one-param tool with zero schema coverage, the description leaves the order_ref format and the destructive side effects unexplained, so it is only adequate.

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?

With 0% schema description coverage, the description must carry parameter meaning, but it only states 'Needs the order_ref' — naming the parameter without supplying format, source, or example. It confirms requiredness but adds essentially no semantics over the bare 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+resource (returns the order's payable link on pinflower.cz) and clarifies that it re-serves the same link while the order is open, guarding against the 'new' in the name. It doesn't explicitly distinguish itself from a sibling like pinflower_get_order_status, which could plausibly also surface order data.

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?

Explicitly names the triggering condition ('buyer has not paid yet and the payment link expired or got lost') and the exclusion ('Not for paid or cancelled orders'), which is strong routing guidance. It stops short of 5 because no sibling alternative is named for the paid/cancelled case.

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/idempotentHint/non-destructive, but the description adds genuinely non-structured context: the returned order_intent, the terms link, and critically 'The total is valid for exactly these details'. It also explains the ask_recipient surprise flow and the free care_reminder behavior, none of which the annotations convey.

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?

It is a long, dense block, but it is front-loaded with the trigger condition and internally ordered with 'Takes:', 'Also on offer:' and 'Returns:' markers. A fair amount of the parameter text duplicates the schema, which dilutes an otherwise efficient layout.

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 an 18-parameter, deeply nested tool, the description covers the required inputs, the conditional rules (10 000 Kč billing threshold, recipient-required flows, one-florist constraint) and the output contract, with an output schema present to carry the return detail. 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 coverage is 72% and the description's parameter prose ('bouquet_id from search', 'several bouquets of ONE florist', 'billing address above 10 000 Kč', address_mode) largely restates what the schema descriptions already say. It frames the required set usefully but adds little syntax or format meaning beyond the structured fields.

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 prices the order exactly as the checkout will charge it') and explicitly distinguishes itself from the write path with 'without creating anything' / 'it creates nothing'. An agent can tell it apart from pinflower_create_order and pinflower_cancel_order without opening a schema.

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 clear trigger: 'Use this when the buyer has chosen what to order and you have the details', and the repeated 'creates nothing' clause implicitly routes the agent to create_order for the actual purchase. However, it never names the alternative tool explicitly, so the exclusion is left to inference.

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 readOnly/idempotent/non-destructive, but the description adds real behavioral context the annotations cannot: every call renders its results to the buyer as a carousel, results are in the storefront's recommended order, and date/deliver_by omission changes the returned timing semantics. Return-value detail matters less because an output schema exists.

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?

Front-loaded with the triggering condition ('Use this when...'), followed by return shape, input framing and the exclusion, in roughly four dense sentences with no filler. Every sentence carries distinct information—nothing restates the title or schema.

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 17-parameter, no-required-parameter tool, it covers role, output shape, the carousel side effect, and scope limits, and an output schema handles return structure. It leaves minor gaps such as how limit/sort interact and default result count, which the schema states but the narrative never hints at.

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 baseline is 3, but the description adds meaning beyond the schema by framing the key inputs as 'what the buyer said' (free text, occasion, budget, where, date, deliver-by), which tells the agent these accept raw conversational phrasing rather than normalized values.

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+resource (search bouquets delivered in Prague) and precisely what the call returns: only bouquets that can arrive at the given place and time, with price, delivery fee, total and earliest delivery time. It also disambiguates from siblings like pinflower_check_delivery and pinflower_get_bouquet by tying itself to concrete purchasable bouquets rather than feasibility checks or single-bouquet lookup.

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 clear when-to-use ('buyer wants flowers delivered in Prague ... and you need concrete bouquets') and explicit when-not ('Not for general flower advice or for orders outside Prague'). It does not name a specific alternative sibling for those excluded cases, so it stops short of full routing 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 declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description still adds useful context: answers are sourced from the shop's own pages and returned with links, which tells the agent the response is authoritative and link-bearing rather than a generic generation.

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, front-loaded with the trigger condition, then the coverage list, then the exclusion. The enumeration is long but every item is a distinct routing cue rather than filler, and there is no redundant or decorative prose.

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 the description need not explain return values. For a read-only informational lookup, what an agent needs (when to call it, what topics it resolves, what it does not resolve, and that responses include links) is all present.

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 single parameter (locale) is fully documented in the schema, including its enum values and default. The description adds nothing about locale or language behavior, so per the high-coverage baseline this is a minimum-viable 3.

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 resource (Pinflower's own informational pages) and enumerates exactly what it covers: payment timing, delivery area/fees, anonymous delivery and card message, absence handling, returns/complaints, and contact. It explicitly excludes bouquet availability, which cleanly separates it from pinflower_get_bouquet and pinflower_search_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?

Opens with an explicit trigger ('Use this when the buyer asks how ordering works...') followed by an exhaustive topic list, and closes with a negative scope ('Does not cover bouquet availability') that routes the agent elsewhere. Both when-to-use and when-not-to-use are stated, leaving nothing to inference.

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