Skip to main content
Glama

Pinflower — flowers in Prague

Order bouquets (pay on pinflower.cz)

pinflower_create_order
DestructiveIdempotent

Use this when the buyer has agreed to the quoted total: it creates the order exactly like the website's checkout and returns the secure payment link on pinflower.cz. Takes the quote's details plus terms_accepted, confirmed_total_czk (the agreed total) and order_intent; if the total has changed meanwhile, nothing is created and it returns the new breakdown instead. Takes: 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; the recipient's name and phone when someone else receives the flowers; the date and a time (one of the bouquet's offered times, or 'asap'); the buyer's name, e-mail and phone (+420…); an optional card message and note for the florist; the buyer's promo code if they have one. Above 10 000 Kč the buyer's billing address is required. Also on offer: address_mode 'ask_recipient' when the florist should agree the address with the recipient by phone — a surprise (the recipient's name and phone are then required); time 'agree_with_recipient' when the florist should agree the time with the recipient by phone (the recipient's name and phone are then required); recipient.care_reminder=true — the free (0 Kč) care reminder for the recipient, offered once when someone else receives the flowers; company details (IČO) for a purchase by a company. Nothing is charged here and the florist is not told until the buyer pays.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes'today', 'tomorrow' or YYYY-MM-DD.
timeYesHH:MM from the offered times, or '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.
bouquet_idNoOne bouquet (shortcut for items with a single line).
florist_idNoThe florist — required when the order is a custom bouquet alone.
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
order_intentYesThe quote's order_intent. The same order_intent always returns the same order (a lost answer is safe to retry); each quote issues a new one.
terms_acceptedYestrue = the buyer agreed to the terms.
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_inNotrue = the buyer asked for news and offers.
confirmed_total_czkYesThe quoted total_czk the buyer agreed to — a different total refuses the order.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pay_urlYes
order_refYes
total_czkYes
order_numberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / recipient / properties / care_reminder
      Added value: +{
      +  "description": "«A little extra care», free (0 Kč), off unless the buyer wants it: after the delivery Pinflower texts the recipient once (the sender ordered a care reminder; STOP opts out), and 3 days later sends one care tip. Delivery only, for a named recipient (recipient.phone is where the texts go — whose number it is does not matter); the recipient's language is unknown, the texts are Czech.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / recipient / properties / sms_opt_out / description
      Previous value: -"true = no SMS to the recipient (keeps a surprise)."New value: +"Legacy, ignored — the recipient is texted only for care_reminder."
  2. Changed8 schema fields changed
    • changedInput schema / properties / confirmed_total_czk / description
      Previous value: -"total_czk from pinflower_quote_order that the buyer agreed to — a different total refuses the order."New value: +"The quoted total_czk the buyer agreed to — a different total refuses the order."
    • changedInput schema / properties / florist_id / description
      Previous value: -"The florist — needed only when the order is a custom bouquet alone."New value: +"The florist — required when the order is a custom bouquet alone."
    • changedInput schema / properties / items / items / properties / addons / description
      Previous value: -"Add-on keys the bouquet offers (pinflower_get_bouquet → addons)."New value: +"Add-on keys the bouquet offers (its details list them as addons)."
    • changedInput schema / properties / items / items / properties / bouquet_id / description
      Previous value: -"From pinflower_search_bouquets / pinflower_get_bouquet."New value: +"A bouquet_id as search results and bouquet details show it."
    • changedInput schema / properties / items / items / properties / custom_budget_czk / description
      Previous value: -"A bouquet composed by the florist to a budget (390–2400 Kč) instead of bouquet_id; put the wishes into florist_note."New value: +"A bouquet composed by the florist to a budget (390–2400 Kč) instead of bouquet_id; the wishes go in florist_note."
    • changedInput schema / properties / marketing_opt_in / description
      Previous value: -"Only true if the buyer asked for news and offers."New value: +"true = the buyer asked for news and offers."
    • changedInput schema / properties / order_intent / description
      Previous value: -"order_intent from pinflower_quote_order. Retrying this call (e.g. the answer got lost) keeps it — the same order comes back; a new purchase needs a new quote."New value: +"The quote's order_intent. The same order_intent always returns the same order (a lost answer is safe to retry); each quote issues a new one."
    • changedInput schema / properties / terms_accepted / description
      Previous value: -"true only after the buyer agreed to the terms."New value: +"true = the buyer agreed to the terms."
  3. Changed2 schema fields changed
    • changedInput schema / properties / recipient / description
      Previous value: -"Who 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."New value: +"Who receives the flowers, when it is someone else than the buyer — the courier calls them."
    • changedInput schema / properties / time / description
      Previous value: -"HH:MM from the offered times, 'asap', or 'agree_with_recipient' (the florist agrees the time with the recipient by phone; delivery only)."New value: +"HH:MM from the offered times, or 'asap', or 'agree_with_recipient' (the florist agrees the time with the recipient by phone; delivery only)."
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources