Skip to main content
Glama

Pinflower — flowers in Prague

Price the order

pinflower_quote_order
Read-onlyIdempotent

Use this when the buyer has chosen what to order and you have the details: it prices the order exactly as the checkout will charge it — the bouquet(s), add-ons, the shop's launch discount or the buyer's promo code, the delivery fee — and checks the time, without creating anything. Collect first: the bouquet(s) (bouquet_id from search; several bouquets of ONE florist with quantities in items); delivery or pickup; for delivery the street address with house number in Prague (or address_mode 'ask_recipient' when the courier should agree the address with the recipient — a surprise); the recipient's name and phone when someone else receives the flowers; the date and a time (one of the times pinflower_get_bouquet offers, or 'asap', or 'agree_with_recipient'); the buyer's name, e-mail and phone (+420…); an optional card message and note for the florist; and ask whether they have a promo code; ask whether it is a purchase for a company (IČO). Above 10 000 Kč the buyer's billing address is required. Read the breakdown and the terms link back to the buyer; after their yes call pinflower_create_order with the same arguments, terms_accepted=true and confirmed_total_czk. Call it again after any change.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes'today', 'tomorrow' or YYYY-MM-DD.
timeYesHH:MM from the offered times, 'asap', or 'agree_with_recipient' (the florist agrees the time with the recipient by phone; delivery only).
unitNoApartment, floor, company at the door.
buyerYes
itemsNoSeveral bouquets from the SAME florist, with quantities.
localeNo
addressNoDelivery to a known address: street and house number in Prague.
companyNoBuying for a company — the invoice is issued to it.
recipientNoWho receives the flowers, when it is someone else than the buyer — the courier calls them; required when the address or the time is agreed with the recipient.
bouquet_idNoOne bouquet (shortcut for items with a single line).
fulfilmentNo
promo_codeNoThe buyer's promo code, if they have one — works for guests and signed-in buyers alike; the checkout checks it.
address_modeNoask_recipient = the courier/florist agrees the address with the recipient by phone (a surprise); no address needed, delivery priced at the whole-city rate.
card_messageNo
courier_noteNoBell name, entrance, gate code.
florist_noteNo
billing_addressNoThe buyer's billing address — required by Czech tax rules when the order is over 10 000 Kč (unless buying for a company).
marketing_opt_inNoOnly true if the buyer asked for news and offers.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
discountNo
goods_czkYes
next_stepYes
terms_urlYes
total_czkYes
delivery_fee_czkYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources