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); add-ons per bouquet (listed in the bouquet details); 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

Name	Required	Description
`date`	Yes	'today', 'tomorrow' or YYYY-MM-DD.
`time`	Yes	HH:MM from the offered times, or 'asap', or 'agree_with_recipient' (the florist agrees the time with the recipient by phone; delivery only).
`unit`	No	Apartment, floor, company at the door.
`buyer`	Yes
`items`	No	Several bouquets from the SAME florist, with quantities.
`locale`	No
`address`	No	Delivery to a known address: street and house number in Prague.
`company`	No	Buying for a company — the invoice is issued to it.
`recipient`	No	Who receives the flowers, when it is someone else than the buyer — the courier calls them.
`bouquet_id`	No	One bouquet (shortcut for items with a single line).
`florist_id`	No	The florist — required when the order is a custom bouquet alone.
`fulfilment`	No
`promo_code`	No	The buyer's promo code, if they have one — works for guests and signed-in buyers alike; the checkout checks it.
`address_mode`	No	ask_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_message`	No
`courier_note`	No	Bell name, entrance, gate code.
`florist_note`	No
`order_intent`	Yes	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.
`terms_accepted`	Yes	true = the buyer agreed to the terms.
`billing_address`	No	The buyer's billing address — required by Czech tax rules when the order is over 10 000 Kč (unless buying for a company).
`marketing_opt_in`	No	true = the buyer asked for news and offers.
`confirmed_total_czk`	Yes	The quoted total_czk the buyer agreed to — a different total refuses the order.

Output Schema

Name	Required	Description	Default
`pay_url`	Yes
`order_ref`	Yes
`total_czk`	Yes
`order_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 11, 2026

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

Changed8 schema fields changedOct 1, 2026

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

Changed2 schema fields changedSep 27, 2026

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

First observedSep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations say this writes (readOnlyHint=false, destructiveHint=true, idempotentHint=true), and the description adds real behavior on top: nothing is charged here, the florist is not told until the buyer pays, and a mismatched confirmed_total_czk aborts the creation. It also explains the safety retry semantics of order_intent and the 0 Kč care_reminder, 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It front-loads the decision condition well, but then turns into a long single-paragraph inventory of fields that the schema already documents at 77% coverage. The core value (when to call, what aborts, what happens with payment) is buried inside that list.

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 22-parameter, nested, open-world write operation with an output schema, the description covers purpose, preconditions, failures and side effects sufficiently. The return values (payment link vs. re-quote breakdown) are described as well, so nothing an agent needs in order to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds cross-field rules the schema does not state: recipient name/phone are required for ask_recipient and agree_with_recipient, billing address is required above 10 000 Kč, add-ons are per bouquet, and care_reminder is free and offered once. Some of this restates schema descriptions verbatim, but the conditional dependencies are genuine added meaning.

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 first sentence states a specific verb and resource (creates the order) plus its precondition (the buyer has agreed to the quoted total) and its outcome (returns the secure payment link on pinflower.cz). That clearly separates it from the sibling pinflower_quote_order, which only quotes.

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 gives explicit when-to-use guidance tied to the quote being accepted, and implicit but clear when-not guidance: if the total changed, nothing is created and the new breakdown comes back instead. It also names the concrete prerequisites and alternatives (address_mode ask_recipient vs known address, time agree_with_recipient, custom bouquet vs bouquet_id), so the agent can decide between the options without guessing.

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

All Pinflower — flowers in Prague tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?