Pinflower — flowers in Prague

Order bouquets (pay on pinflower.cz)

pinflower_create_order

Use this when the buyer has agreed to the total from pinflower_quote_order: it creates the order exactly like the website's checkout and returns the secure payment link on pinflower.cz. Pass the same arguments as the quote, terms_accepted=true and confirmed_total_czk = the total the buyer agreed to; if the total has changed meanwhile, nothing is created and you get the new breakdown to read back. 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. Nothing is charged here and the florist is not told until the buyer pays.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	'today', 'tomorrow' or YYYY-MM-DD.
`time`	Yes	HH:MM from the offered times, '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; required when the address or the time is agreed with the recipient.
`bouquet_id`	No	One bouquet (shortcut for items with a single line).
`florist_id`	No	The florist — needed only 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	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.
`terms_accepted`	Yes	true only after 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	Only true if the buyer asked for news and offers.
`confirmed_total_czk`	Yes	total_czk from pinflower_quote_order that the buyer agreed to — a different total refuses the order.

Output Schema

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

First observedSep 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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?