Skip to main content
Glama

Suorigo Konfigurátor

by cz.suorigo.konfigurator
OverviewDiscussionsAdmin

Server Details

Potisk triček a textilu na míru (ČR) — katalog, ceny, příprava designu a objednávky.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
98.6% over 58 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored across 10 tools

Disambiguation4/5

Most tools target a clearly distinct resource+action (design, order, payment link, status, pickup points, products, company), and descriptions are detailed and explicit. The only real overlap is get_quote vs quote_order, both price estimators, but the descriptions clearly scope one to a single product and the other to the full order, so confusion is limited.

Naming Consistency5/5

All ten tools use a consistent snake_case verb_noun pattern (cancel_order, create_design, create_order, find_pickup_points, get_order_status, get_payment_link, get_quote, list_products, lookup_company, quote_order). No mixed conventions or vague verb styles.

Tool Count5/5

With 10 tools this is well-scoped for a custom-print e-commerce server; each tool covers a distinct step (catalog, design, quoting, ordering, payment, status, cancel, shipping, company lookup). Nothing feels redundant or missing at the count level.

Completeness4/5

The purchase lifecycle is largely covered: catalog, design, quoting, ordering, payment link retrieval, status, cancellation, pickup points, and company lookup. Minor gaps remain (no order history/list for the customer, no explicit refund or reorder path, cancellation limited to unpaid orders), but core workflows are complete.

Available Tools

10 tools
cancel_orderA
DestructiveIdempotent
Inspect

Stornuje NEZAPLACENOU objednávku, která ještě není ve výrobě — stejně jako tlačítko na stránce stavu (zákazník dostane e-mail o stornu, otevřená platba kartou se zavře). Zaplacenou objednávku stornovat nejde (napiš na potisk@suorigo.cz). Jen se statusToken a jen na výslovný pokyn zákazníka.

ParametersJSON Schema
NameRequiredDescriptionDefault
statusTokenYesstatusToken z create_order (poslední část statusUrl) — plný přístup

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds valuable behavioral context: the customer receives a cancellation email, an open card payment is closed, and the operation is restricted to unpaid orders. It also adds the constraint that it must be done only on explicit customer instruction. The idempotentHint=true annotation is not contradicted; the description doesn't claim non-idempotency. Slight gap: no mention of what happens if the order is already in production, but the 'not yet in production' condition implies it.

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?

The description is compact but information-dense. Every sentence earns its place: the condition, the effect, the exclusion, the fallback contact, and the authorization constraint. It is front-loaded with the most important condition (unpaid, not in production).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with a clear schema and annotations, the description covers the essential context: what it does, when it's allowed, what side effects occur, and what to do when it can't be used. The only minor gap is not explicitly stating the behavior for an order already in production, but the 'not yet in production' condition implies it's not cancellable via this tool.

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?

Schema coverage is 100%, so the schema already documents the statusToken parameter. The description adds meaning by explaining where the token comes from (last part of statusUrl from create_order) and that it grants full access, which is useful context beyond the schema's bare description.

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 clearly states the tool cancels an UNPAID order not yet in production, and explicitly says paid orders cannot be cancelled. It distinguishes itself from sibling tools by naming the exact condition (unpaid, not in production) and the action (same as the button on the status page).

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?

The description gives explicit when-to-use guidance: only with a statusToken, only on explicit customer instruction, and only for unpaid orders not yet in production. It also tells the agent what to do if the order is paid (write to potisk@suorigo.cz), which is a clear alternative path.

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

create_designAInspect

Zvaliduje a uloží design (logo/text na stranách trička): vrátí vrstvy s nahranými URL pro create_order, orientační příplatek za potisk a previewUrl — odkaz, kde zákazník uvidí návrh na tričku v konfigurátoru (a může ho tam i sám objednat).

ParametersJSON Schema
NameRequiredDescriptionDefault
layersYesvrstvy: {type:'image'|'text', side:'front'|'back'|'sideLeft'|'sideRight', x,y,width,height v % 0–100, rotation?, src? (https URL nebo data:URL obrázku), text?, fontFamily?, fontSize?, fill?}
colorIdNo
productYes
previewBackDataUrlNo
previewFrontDataUrlNo

TDQS

A3.5/5.0
Behavior4/5

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

With all annotation hints false, the description carries the behavioral burden — and it delivers: it discloses persistence ('uloží' — saves), an upload side effect (returns layers with uploaded URLs), that the surcharge is only indicative ('orientační'), and that the design becomes customer-visible/orderable via the previewUrl. No contradiction with annotations; only validation-failure behavior is left undisclosed.

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?

The description is one dense, run-on compound sentence packing validation, saving, three return values, and a customer-ordering detail. It is front-loaded with the core action, but the structure hurts scannability; splitting into two or three sentences would improve readability without adding length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with 20% schema coverage, no output schema, and all-false annotations, the description must carry more weight. It explains return values well (needed since no output schema exists) and the workflow, but leaves the required 'product' parameter and other three optional parameters completely unexplained — an agent cannot reliably invoke this tool correctly without guessing their formats.

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

Parameters2/5

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

Schema description coverage is only 20% — four of five parameters (colorId, product, previewBackDataUrl, previewFrontDataUrl) are undocumented in the schema, and the description does not compensate for any of them. The layers parameter has a rich inline schema description, but the tool description itself adds no parameter-level meaning beyond the phrase 'logo/text na stranách trička', which loosely maps to layers content only.

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 states a specific action ('Zvaliduje a uloží design' — validates and saves a design) with a specific resource (logo/text on t-shirt sides). It goes beyond the title 'Připravit design' by detailing what it returns (uploaded layer URLs, surcharge, previewUrl) and clearly positions itself as the preparation step feeding into create_order, distinguishing it from order-creation and quoting siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied through workflow references: the returned layers are 'pro create_order' (for create_order), and the previewUrl lets the customer order from the configurator. This tells the agent this tool precedes order creation, but there are no explicit when-not-to-use conditions or comparisons against alternatives like get_quote or quote_order.

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

create_order
Idempotent
Inspect

Založí ZÁVAZNOU objednávku (čeká na platbu). paymentMethod 'bank_transfer' (výchozí) vrátí číslo účtu, variabilní symbol a QR; 'card' vrátí paymentUrl — zabezpečenou stránku Stripe pro tuto objednávku, kde zákazník sám zadá kartu (agent kartu nikdy nezadává ani nevidí; po zaplacení jede faktura a výroba stejně jako u objednávky z webu). Vždy vrátí statusUrl a statusToken (pro get_order_status, get_payment_link, cancel_order) a zákazníkovi pošle e-mail. Volej až po výslovném souhlasu zákazníka s položkami a cenou z quote_order. Povinné: skutečný e-mail (doména musí přijímat poštu, jinak 422), jméno a příjmení, shippingId (+ pickupPointId u výdejního místa, jinak adresa), consent:true; nad 10 000 Kč bez IČO fakturační adresa. Kartou nejméně 15 Kč. Nezaplacená karta propadne po 48 h, převod po 7 dnech. Limity: 3 objednávky / IP / den, 2 nezaplacené a 3 objednávky za 24 h na e-mail (429). Při opakování po timeoutu pošli stejný idempotencyKey.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemsYespoložky objednávky (každá velikost/barva zvlášť)
notesNovzkaz zákazníka k objednávce (co má dílna vědět); uloží se k zakázce jako poznámka od zákazníka, delší text se ořízne
consentYessouhlas zákazníka s obchodními podmínkami (https://suorigo.cz/obchodni-podminky), musí být true
customerYeszákazník: email (povinné, skutečná doména s poštou), name (povinné — jméno A příjmení, jde na daňový doklad), phone?, address? (doručovací adresa jedním řádkem u doručení na adresu) nebo deliveryStreet/deliveryCity/deliveryZip, firma: companyName?, ico? (doplní se z ARES), dic?, fakturační adresa billingStreet/billingCity/billingZip/billingCountry (nad 10 000 Kč bez IČO povinná)
promoCodeNoslevový kód; neplatný kód = chyba (nikdy tiše plná cena)
shippingIdYesdoprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (69 Kč), dpd-vydejni (89 Kč), ppl (na adresu, 119 Kč), dpd (na adresu, 109 Kč); od 1 500 Kč zdarma
paymentMethodNobank_transfer = převod + QR (výchozí); card = odkaz na platbu kartou (Stripe Checkout, Apple/Google Pay podle prohlížeče)
pickupPointIdNoid výdejního místa z find_pickup_points (povinné u dopravy na výdejní místo)
idempotencyKeyNolibovolný unikátní klíč této objednávky (např. UUID); opakované volání se stejným klíčem a obsahem vrátí stejnou objednávku (replayed:true, u karty tentýž platební odkaz), stejný klíč s jiným obsahem = 409
deliverySpeedIdNotermín: d14 = do 14 prac. dní (výchozí, bez příplatku), d7 = do 7 dní +30 % (jen trička Standard), d30 = do měsíce −10 %; nedostupný termín = 400 s důvodem (quote_order ukáže dostupnost)
pickupPointNameNonázev výdejního místa (volitelné, doplní se samo)
find_pickup_pointsA
Read-only
Inspect

Vyhledá výdejní místa dopravce podle města, PSČ, ulice nebo názvu (Zásilkovna vč. Z-BOXů, Balíkovna, PPL ParcelShop, DPD Pickup). Vrácené id patří do create_order.pickupPointId.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNopočet výsledků (výchozí 10)
queryYesměsto, PSČ, ulice nebo název (min. 2 znaky), např. „Brno Lidická“ nebo „60200“
shippingIdYes

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds useful integration context by noting the returned id is meant for create_order, but it does not describe response shape, pagination, availability, or provider-specific caveats.

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?

Two sentences, front-loaded with the core action and followed by the integration note. There is no filler, repetition, or unnecessary detail; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter lookup tool with annotations and no output schema, the description provides enough to call it correctly: carriers, search criteria, and the meaning of the returned id. A minor gap is that it does not mention what other fields appear in results, but the tool's evident purpose is to supply an id for order creation.

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 schema documents query and limit, but shippingId has no description. The description's carrier list ('Zásilkovna vč. Z-BOXů, Balíkovna, PPL ParcelShop, DPD Pickup') gives human-readable meaning to the otherwise opaque enum values, and it reinforces query semantics with city/PSČ/street/name examples.

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 opens with a specific verb and resource: 'Vyhledá výdejní místa dopravce' (searches carrier pickup points), lists the supported carriers, and states the search dimensions. It is clearly distinct from the order/catalog siblings and directly explains what the tool returns.

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 sentence 'Vrácené id patří do create_order.pickupPointId' clearly frames the tool as a prerequisite lookup step before order creation. It establishes the intended usage context, though it does not explicitly name alternative tools or when-not-to-use conditions.

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

get_order_statusA
Read-only
Inspect

Stav objednávky: platba (pending/paid/failed/refunded), výroba (new → shipped/delivered, cancelled), očekávaný termín. Se statusToken navíc statusUrl, faktura (PDF po zaplacení) a sledování zásilky. S orderNumber + email jen základní stav (čísla objednávek jsou předvídatelná). Neshoda = found:false.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailNoe-mail zákazníka z objednávky — jen spolu s orderNumber
orderNumberNočíslo objednávky (9 číslic) — jen spolu s e-mailem
statusTokenNostatusToken z create_order (poslední část statusUrl) — plný přístup

TDQS

A4/5.0
Behavior4/5

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

Annotations already mark this as read-only, and the description adds context beyond that: it explains the different output richness depending on the provided parameters, and warns that order numbers are predictable (a security consideration). It doesn't contradict annotations. The description effectively conveys behavioral nuances such as the fact that the tool is safe but may return partial or no data depending on input.

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 a single dense paragraph, but it front-loads the core purpose and then details the two access modes concisely. While it could be split into clearer bullet points, every sentence adds value and there's no redundancy. It's efficient and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return values, and it does so well: it lists payment statuses, production statuses, expected date, and additional fields available with the token. A notable gap is the behavior when no parameters are provided (none are required), which is not addressed. Overall, it's nearly complete for a read‑only status tool.

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?

Schema description coverage is 100%, so parameters are already documented. The description adds meaningful semantics by clarifying that orderNumber and email must be used together, and that statusToken (the last part of statusUrl) provides full access. This goes beyond the schema's plain descriptions and helps the agent construct correct calls.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides order status ('Stav objednávky') and enumerates the specific data it returns: payment status, production status, and expected date. It distinguishes between basic and full access based on the token, giving a clear sense of the tool's scope. However, it does not explicitly name alternative sibling tools or contrast its purpose with them, so it's slightly below a perfect score.

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 description gives concrete usage guidance: using statusToken grants full access (including statusUrl, invoice, and tracking), whereas orderNumber + email yields only basic status. It also notes that mismatches result in found:false. This implies when and how to call the tool, but it stops short of explicitly stating when to choose this over other order-related tools like get_payment_link or get_quote, so it's not a 5.

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

get_quoteA
Read-only
Inspect

Rychlý odhad ceny JEDNOHO produktu (vč. DPH) podle množství/velikostí a počtu potištěných stran. Přesnou cenu celé objednávky (doprava, kupón, termín) vrací quote_order.

ParametersJSON Schema
NameRequiredDescriptionDefault
sizesNomapování velikost→počet, např. {"M":10,"L":5}
productYes
quantityNo
promoCodeNo
printedSidesNopočet potištěných stran 0–4
printSideHeightsCmNovýška motivu v cm na každé potištěné straně

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context: the result is a rapid estimate, includes VAT, is scoped to one product, and is not the final order price. There is no contradiction with annotations.

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?

The description is two tight sentences with the primary action front-loaded and the sibling distinction in the second sentence. Every phrase contributes meaning, and there is no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for tool selection and basic routing, but for a 6-parameter tool with a nested sizes object and no output schema, it would benefit from clarifying which parameters are expected together and how print-side heights are used. The sibling mention mitigates this partially, but invocation details remain incomplete.

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

Parameters3/5

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

Schema description coverage is 50%, and the description adds some domain meaning by naming quantity/sizes and number of printed sides as price drivers. However, it does not clarify the required 'product' parameter, the role of 'promoCode', or how 'printSideHeightsCm' relates to the estimate, leaving part of the invocation behavior under-specified.

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 states a specific verb and resource: 'Rychlý odhad ceny JEDNOHO produktu (vč. DPH)', i.e., a quick price estimate for a single product including VAT. It also explicitly contrasts itself with quote_order, which returns the exact full-order price, clearly differentiating it from the sibling 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?

The description provides explicit routing guidance: use this tool for a quick single-product estimate, and use quote_order for the exact order total including shipping, coupon, and delivery date. This is a clear when-to-use / when-not-to-use statement with a named alternative.

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

list_productsA
Read-only
Inspect

Vrátí katalog triček/mikin Suorigo (barvy, velikosti, ceny vč. množstevních slev) nebo jeden produkt podle id/slug.

ParametersJSON Schema
NameRequiredDescriptionDefault
productNoid nebo slug konkrétního produktu (volitelné)

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only behavior is known. The description adds context about the returned data (colors, sizes, prices, discounts) and that output varies based on whether the product parameter is provided.

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?

One concise sentence that front-loads the action and resource, contains no filler, and is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, with one optional parameter, full schema coverage, and annotations covering safety. The description adequately explains the return behavior. Although it does not mention pagination or response format, these are not essential for this low-complexity tool.

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

Parameters3/5

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

The schema fully describes the optional 'product' parameter as id/slug, and the description echoes that role. However, it does not add extra syntax or formatting details. With 100% schema coverage, the baseline of 3 applies.

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 clearly states it returns a catalog of Suorigo t-shirts/hoodies (colors, sizes, prices, discounts) or a single product by id/slug. The verb and resource are specific, and it is easily distinguished from sibling tools like create_order or get_quote.

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 description implies when to use it: to fetch product catalog or a specific product. It does not explicitly name alternatives or exclusions, but the sibling tool names are distinct enough that no ambiguity arises.

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

lookup_companyA
Read-only
Inspect

Dohledá firmu podle IČO v ARES (název, DIČ, sídlo) — pro nákup na firmu. Vrací pole ve tvaru create_order.customer (companyName, ico, dic, billingStreet…).

ParametersJSON Schema
NameRequiredDescriptionDefault
icoYesIČO (7–8 číslic)

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false), and the description adds worthwhile behavioral context: it queries the external ARES registry and returns a structured customer-shaped object. It does not disclose failure modes or rate limits, but for a read-only lookup this is a minor gap given the annotation coverage.

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?

A single sentence packs purpose, data source, returned fields, use case, and output shape into a compact definition. No filler or repetition; the most important information is front-loaded.

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 one-parameter read-only lookup with no output schema, the description is complete: it explains the source, the data returned, the output shape reference, and the intended business scenario. An agent has enough to call the tool correctly and map the result forward into an order.

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

Parameters3/5

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

Schema coverage is 100% and the schema already documents ico as 'IČO (7–8 číslic)'. The description repeats the IČO concept but adds little beyond schema semantics; it does confirm the parameter identifies the company to look up in ARES. Baseline 3 is appropriate because the schema carries the parameter-meaning burden.

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 states a specific action ('Dohledá firmu podle IČO v ARES'), identifies the exact resource (ARES registry), and lists the data returned (název, DIČ, sídlo). It also ties the result to a concrete use case ('pro nákup na firmu') and connects the output shape to create_order.customer, making it easy for an agent to distinguish this lookup tool from order-management 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 description clearly indicates when this tool is relevant: when purchasing as a company and you need Czech company details by IČO. It does not explicitly name sibling alternatives or state when not to use it, but the ARES-specific lookup intent and the create_order.customer output shape provide enough contextual guidance.

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

quote_order
Read-only
Inspect

Přesná cena celé objednávky PŘED založením — stejný výpočet jako create_order (položky, doprava vč. dopravy zdarma od 1 500 Kč, kupón, termín výroby). Vrací totalVat, rozpis, dostupné termíny (deliverySpeeds), ceny dopravy a v requirements co ještě chybí k objednání. Nic neukládá.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemsYespoložky objednávky (každá velikost/barva zvlášť)
customerNovolitelné: email (kvůli limitu kupónu), name, ico, adresy — jen pro kontrolu requirements
promoCodeNoslevový kód; neplatný kód = chyba (nikdy tiše plná cena)
shippingIdNodoprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (69 Kč), dpd-vydejni (89 Kč), ppl (na adresu, 119 Kč), dpd (na adresu, 109 Kč); od 1 500 Kč zdarma
pickupPointIdNoid výdejního místa z find_pickup_points (povinné u dopravy na výdejní místo)
deliverySpeedIdNotermín: d14 = do 14 prac. dní (výchozí, bez příplatku), d7 = do 7 dní +30 % (jen trička Standard), d30 = do měsíce −10 %; nedostupný termín = 400 s důvodem (quote_order ukáže dostupnost)
pickupPointNameNonázev výdejního místa (volitelné, doplní se samo)

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Changedcreate_order1 field changed
      • changedInput schema / properties / shippingId / description
        Previous value: -"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (79 Kč), dpd-vydejni (89 Kč), ppl / dpd (na adresu, 129 Kč); od 1 500 Kč zdarma"New value: +"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (69 Kč), dpd-vydejni (89 Kč), ppl (na adresu, 119 Kč), dpd (na adresu, 109 Kč); od 1 500 Kč zdarma"
    • Changedquote_order1 field changed
      • changedInput schema / properties / shippingId / description
        Previous value: -"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (79 Kč), dpd-vydejni (89 Kč), ppl / dpd (na adresu, 129 Kč); od 1 500 Kč zdarma"New value: +"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (69 Kč), dpd-vydejni (89 Kč), ppl (na adresu, 119 Kč), dpd (na adresu, 109 Kč); od 1 500 Kč zdarma"
  2. 2 tool updates
    • Changedcreate_order2 fields changed
      • changedInput schema / properties / shippingId / description
        Previous value: -"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (79 Kč), dpd-vydejni (89 Kč), ppl / dpd (na adresu, 129 Kč); od 1 500 Kč zdarma; osobni (Šitbořice) jen se slevovým kódem, který ho odemyká"New value: +"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (79 Kč), dpd-vydejni (89 Kč), ppl / dpd (na adresu, 129 Kč); od 1 500 Kč zdarma"
      • changedInput schema / properties / shippingId / enum
        Previous value: -[
-  "zasilkovna",
-  "balikovna",
-  "ppl-vydejni",
-  "dpd-vydejni",
-  "ppl",
-  "dpd",
-  "osobni"
-]New value: +[
+  "zasilkovna",
+  "balikovna",
+  "ppl-vydejni",
+  "dpd-vydejni",
+  "ppl",
+  "dpd"
+]
    • Changedquote_order2 fields changed
      • changedInput schema / properties / shippingId / description
        Previous value: -"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (79 Kč), dpd-vydejni (89 Kč), ppl / dpd (na adresu, 129 Kč); od 1 500 Kč zdarma; osobni (Šitbořice) jen se slevovým kódem, který ho odemyká"New value: +"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (79 Kč), dpd-vydejni (89 Kč), ppl / dpd (na adresu, 129 Kč); od 1 500 Kč zdarma"
      • changedInput schema / properties / shippingId / enum
        Previous value: -[
-  "zasilkovna",
-  "balikovna",
-  "ppl-vydejni",
-  "dpd-vydejni",
-  "ppl",
-  "dpd",
-  "osobni"
-]New value: +[
+  "zasilkovna",
+  "balikovna",
+  "ppl-vydejni",
+  "dpd-vydejni",
+  "ppl",
+  "dpd"
+]
  3. 2 tool updates
    • Changedcreate_order3 fields changed
      • changedInput schema / properties / deliverySpeedId / description
        Previous value: -"termín: d14 = do 14 prac. dní (výchozí, bez příplatku), d7 = do 7 dní +30 % (jen trička Standard), rush3 = expres do 3 prac. dnů +100 % (jen černá/bílá trička Standart, objednávka 1 500–5 000 Kč, podání do 12:00), d30 = do měsíce −10 %; nedostupný termín = 400 s důvodem (quote_order ukáže dostupnost)"New value: +"termín: d14 = do 14 prac. dní (výchozí, bez příplatku), d7 = do 7 dní +30 % (jen trička Standard), d30 = do měsíce −10 %; nedostupný termín = 400 s důvodem (quote_order ukáže dostupnost)"
      • changedInput schema / properties / deliverySpeedId / enum
        Previous value: -[
-  "rush3",
-  "d7",
-  "d14",
-  "d30"
-]New value: +[
+  "d7",
+  "d14",
+  "d30"
+]
      • changedInput schema / properties / items / items / properties / colorName / description
        Previous value: -"název barvy (rozhoduje i o expresu: jen černá/bílá)"New value: +"název barvy"
    • Changedquote_order3 fields changed
      • changedInput schema / properties / deliverySpeedId / description
        Previous value: -"termín: d14 = do 14 prac. dní (výchozí, bez příplatku), d7 = do 7 dní +30 % (jen trička Standard), rush3 = expres do 3 prac. dnů +100 % (jen černá/bílá trička Standart, objednávka 1 500–5 000 Kč, podání do 12:00), d30 = do měsíce −10 %; nedostupný termín = 400 s důvodem (quote_order ukáže dostupnost)"New value: +"termín: d14 = do 14 prac. dní (výchozí, bez příplatku), d7 = do 7 dní +30 % (jen trička Standard), d30 = do měsíce −10 %; nedostupný termín = 400 s důvodem (quote_order ukáže dostupnost)"
      • changedInput schema / properties / deliverySpeedId / enum
        Previous value: -[
-  "rush3",
-  "d7",
-  "d14",
-  "d30"
-]New value: +[
+  "d7",
+  "d14",
+  "d30"
+]
      • changedInput schema / properties / items / items / properties / colorName / description
        Previous value: -"název barvy (rozhoduje i o expresu: jen černá/bílá)"New value: +"název barvy"
  4. 8 tool updates
    • Addedcancel_order
    • Changedcreate_design1 field changed
      • changedInput schema / properties / layers / description
        Previous value: -"vrstvy: {type:'image'|'text', side:'front'|'back'|'sideLeft'|'sideRight', x,y,width,height v % 0–100, rotation?, src? (URL nebo data:URL obrázku), text?, fontFamily?, fontSize?, fill?}"New value: +"vrstvy: {type:'image'|'text', side:'front'|'back'|'sideLeft'|'sideRight', x,y,width,height v % 0–100, rotation?, src? (https URL nebo data:URL obrázku), text?, fontFamily?, fontSize?, fill?}"
    • Changedcreate_order16 fields changed
      • changedInput schema / properties / consent / description
        Previous value: -"souhlas s obchodními podmínkami, musí být true"New value: +"souhlas zákazníka s obchodními podmínkami (https://suorigo.cz/obchodni-podminky), musí být true"
      • changedInput schema / properties / customer / description
        Previous value: -"{email (povinné), name?, phone?, address?, companyName?, ico?, dic?, billingStreet?, billingCity?, billingZip?, billingCountry?}"New value: +"zákazník: email (povinné, skutečná doména s poštou), name (povinné — jméno A příjmení, jde na daňový doklad), phone?, address? (doručovací adresa jedním řádkem u doručení na adresu) nebo deliveryStreet/deliveryCity/deliveryZip, firma: companyName?, ico? (doplní se z ARES), dic?, fakturační adresa billingStreet/billingCity/billingZip/billingCountry (nad 10 000 Kč bez IČO povinná)"
      • addedInput schema / properties / customer / properties
        Added value: +{
+  "address": {
+    "type": "string"
+  },
+  "billingCity": {
+    "type": "string"
+  },
+  "billingCountry": {
+    "type": "string"
+  },
+  "billingStreet": {
+    "type": "string"
+  },
+  "billingZip": {
+    "type": "string"
+  },
+  "companyName": {
+    "type": "string"
+  },
+  "deliveryCity": {
+    "type": "string"
+  },
+  "deliveryStreet": {
+    "type": "string"
+  },
+  "deliveryZip": {
+    "type": "string"
+  },
+  "dic": {
+    "type": "string"
+  },
+  "email": {
+    "type": "string"
+  },
+  "ico": {
+    "type": "string"
+  },
+  "name": {
+    "type": "string"
+  },
+  "phone": {
+    "type": "string"
+  }
+}
      • addedInput schema / properties / customer / required
        Added value: +[
+  "email",
+  "name"
+]
      • addedInput schema / properties / deliverySpeedId
        Added value: +{
+  "description": "termín: d14 = do 14 prac. dní (výchozí, bez příplatku), d7 = do 7 dní +30 % (jen trička Standard), rush3 = expres do 3 prac. dnů +100 % (jen černá/bílá trička Standart, objednávka 1 500–5 000 Kč, podání do 12:00), d30 = do měsíce −10 %; nedostupný termín = 400 s důvodem (quote_order ukáže dostupnost)",
+  "enum": [
+    "rush3",
+    "d7",
+    "d14",
+    "d30"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / idempotencyKey / description
        Previous value: -"libovolný unikátní klíč této objednávky (např. UUID); opakované volání se stejným klíčem a obsahem vrátí stejnou objednávku (replayed:true), stejný klíč s jiným obsahem = 409"New value: +"libovolný unikátní klíč této objednávky (např. UUID); opakované volání se stejným klíčem a obsahem vrátí stejnou objednávku (replayed:true, u karty tentýž platební odkaz), stejný klíč s jiným obsahem = 409"
      • changedInput schema / properties / items / description
        Previous value: -"položky: {product (id/slug), colorId?, colorName?, size, quantity, printMethod?, layers? (z create_design)}"New value: +"položky objednávky (každá velikost/barva zvlášť)"
      • addedInput schema / properties / items / items / properties
        Added value: +{
+  "colorId": {
+    "type": "string"
+  },
+  "colorName": {
+    "description": "název barvy (rozhoduje i o expresu: jen černá/bílá)",
+    "type": "string"
+  },
+  "layers": {
+    "description": "vrstvy z create_design (určují příplatek za potisk)",
+    "items": {
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "printMethod": {
+    "type": "string"
+  },
+  "product": {
+    "description": "id nebo slug produktu z list_products",
+    "type": "string"
+  },
+  "quantity": {
+    "minimum": 1,
+    "type": "integer"
+  },
+  "size": {
+    "description": "velikost z katalogu, např. M",
+    "type": "string"
+  }
+}
      • addedInput schema / properties / items / items / required
        Added value: +[
+  "product",
+  "size",
+  "quantity"
+]
      • addedInput schema / properties / paymentMethod
        Added value: +{
+  "description": "bank_transfer = převod + QR (výchozí); card = odkaz na platbu kartou (Stripe Checkout, Apple/Google Pay podle prohlížeče)",
+  "enum": [
+    "bank_transfer",
+    "card"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / pickupPointId
        Added value: +{
+  "description": "id výdejního místa z find_pickup_points (povinné u dopravy na výdejní místo)",
+  "type": "string"
+}
      • addedInput schema / properties / pickupPointName
        Added value: +{
+  "description": "název výdejního místa (volitelné, doplní se samo)",
+  "type": "string"
+}
      • addedInput schema / properties / promoCode / description
        Added value: +"slevový kód; neplatný kód = chyba (nikdy tiše plná cena)"
      • changedInput schema / properties / shippingId / description
        Previous value: -"např. 'zasilkovna','balikovna','ppl','dpd' (volitelné)"New value: +"doprava: zasilkovna (výdejní místo / Z-BOX, 89 Kč), balikovna (69 Kč), ppl-vydejni (79 Kč), dpd-vydejni (89 Kč), ppl / dpd (na adresu, 129 Kč); od 1 500 Kč zdarma; osobni (Šitbořice) jen se slevovým kódem, který ho odemyká"
      • addedInput schema / properties / shippingId / enum
        Added value: +[
+  "zasilkovna",
+  "balikovna",
+  "ppl-vydejni",
+  "dpd-vydejni",
+  "ppl",
+  "dpd",
+  "osobni"
+]
      • changedInput schema / required
        Previous value: -[
-  "items",
-  "customer",
-  "consent"
-]New value: +[
+  "items",
+  "customer",
+  "shippingId",
+  "consent"
+]
    • Addedfind_pickup_points
    • Changedget_order_status4 fields changed
      • changedInput schema / properties / email / description
        Previous value: -"e-mail zákazníka použitý v objednávce"New value: +"e-mail zákazníka z objednávky — jen spolu s orderNumber"
      • changedInput schema / properties / orderNumber / description
        Previous value: -"číslo objednávky z create_order (9 číslic)"New value: +"číslo objednávky (9 číslic) — jen spolu s e-mailem"
      • addedInput schema / properties / statusToken
        Added value: +{
+  "description": "statusToken z create_order (poslední část statusUrl) — plný přístup",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "orderNumber",
-  "email"
-]New value: +[]
    • Addedget_payment_link
    • Addedlookup_company
    • Addedquote_order
  5. 2 tool updates
    • Changedcreate_order1 field changed
      • addedInput schema / properties / idempotencyKey
        Added value: +{
+  "description": "libovolný unikátní klíč této objednávky (např. UUID); opakované volání se stejným klíčem a obsahem vrátí stejnou objednávku (replayed:true), stejný klíč s jiným obsahem = 409",
+  "maxLength": 128,
+  "type": "string"
+}
    • Changedget_order_status3 fields changed
      • addedInput schema / properties / email
        Added value: +{
+  "description": "e-mail zákazníka použitý v objednávce",
+  "type": "string"
+}
      • addedInput schema / properties / orderNumber / description
        Added value: +"číslo objednávky z create_order (9 číslic)"
      • changedInput schema / required
        Previous value: -[
-  "orderNumber"
-]New value: +[
+  "orderNumber",
+  "email"
+]
  6. 1 tool update
    • Changedcreate_order2 fields changed
      • addedInput schema / properties / notes / description
        Added value: +"vzkaz zákazníka k objednávce (co má dílna vědět); uloží se k zakázce jako poznámka od zákazníka, delší text se ořízne"
      • addedInput schema / properties / notes / maxLength
        Added value: +1000
  7. 5 tool updates
    • First observedcreate_design
    • First observedcreate_order
    • First observedget_order_status
    • First observedget_quote
    • First observedlist_products

Related MCP Connectors

Related MCP Servers

  • agentee-mcp

    alloverart
    A
    license
    Not graded
    quality
    C
    maintenance
    Remote MCP server for the allover.art print-on-demand store: search 30,000+ all-over-print 100% cotton tees, build and edit a cart, apply promo codes and prepare checkout.
    1
    MIT
  • Shoptera Product Intelligence by shoptera-ai

    Shoptera Product Intelligenceofficial

    shoptera-ai
    A
    license
    Not graded
    quality
    D
    maintenance
    Search product catalogs across thousands of Central European e-shops. Semantic search, keyword matching, GTIN/EAN lookup — via REST API or MCP. \~2,500 e-shops | ~8.5M products | 7 countries (CZ, SK, PL, HU, RO, DE, AT)
    MIT

  • cz-mtg-compare-mcp

    xvyslo05
    A
    license
    A
    quality
    D
    maintenance
    Lets Claude compare Magic: The Gathering single-card prices across six Czech online card shops, with optional Cardmarket fallback. Queries all shops in parallel and returns a normalized, price-sorted list.
    10
    3
    MIT
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