Ceník SHOPZI, volné subdomény, založení nového e-shopu a hledání v dokumentaci. Bez klíče.
Scored across 5 tools
Each tool targets a distinct step of the store-creation flow: subdomain availability, store draft creation, plan listing, creation status, and documentation lookup. There is no realistic overlap that could cause misselection, and the descriptions explicitly cross-reference each other (create_store points to store_creation_status). The only mild dual-purpose element is shopzi_docs with search/read modes, but that is clearly parameterized.
All names share the shopzi_ prefix and snake_case, which is highly predictable. However, two tools are noun phrases (shopzi_docs, shopzi_store_creation_status) while the others follow the verb_noun pattern (check_subdomain, create_store, list_plans), a minor deviation.
Five tools is a well-scoped surface for a narrow onboarding workflow, and each one covers a necessary step (discover plans, check subdomain, create draft, poll status, read docs). Nothing appears redundant or padded.
The core lifecycle — check subdomain, pick plan, create draft, track completion, consult docs — is covered with no dead ends. Minor gaps remain: no way to cancel/abandon a draft, change the subdomain or plan after creation, or list already-existing stores for the user.
Ověří, jestli je subdoména pro nový obchod volná (nazev.shopzi.cz). Vrátí ano/ne, důvod a volné varianty odvozené z dotazu. Nikdy neprozradí, komu obsazená subdoména patří.
| Name | Required | Description | Default |
|---|---|---|---|
| subdomain | Yes | Požadovaná subdoména, například `cerstva-kava` pro cerstva-kava.shopzi.cz. Přípona `.shopzi.cz` se smí uvést. |
| Name | Required | Description |
|---|---|---|
| reason | Yes | |
| message | Yes | |
| available | Yes | |
| subdomain | Yes | Subdoména po normalizaci, na kterou se odpověď vztahuje. |
| suggestions | Yes | Volné varianty odvozené z dotazu. Prázdné, když je subdoména volná. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the remaining burden is light. The description adds real value beyond them: it discloses the privacy guarantee ('Nikdy neprozradí, komu obsazená subdoména patří') and that suggestions come back with the answer, which an agent cannot infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core question and followed by the return shape and the privacy caveat. Slightly wasteful since the return-value sentence partly duplicates the existing output schema, but nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A single-parameter, read-only check with an output schema — the description covers the privacy behavior and suggestion output, which is the part not visible elsewhere. Only the pre-creation sequencing with shopzi_create_store is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains the input, the `.shopzi.cz` suffix handling, and the length bounds. The description only restates the domain format, adding no new parameter-level meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Ověří, jestli je subdoména ... volná') with the concrete format `nazev.shopzi.cz`, making it immediately distinguishable from siblings like shopzi_create_store or shopzi_store_creation_status. An agent can route to it without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'pro nový obchod' implies this is a pre-creation availability check, but the description never names shopzi_create_store or states that this should be called before it, nor does it state what to do when the result is occupied. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Založí KONCEPT nového obchodu a podrží pro něj subdoménu. Obchod ještě nevznikne: člověk otevře draft_url v prohlížeči, zadá pairing_code, ověří e-mail a přijme podmínky. Tarif free vznikne hned potom, bez platební karty. Placený tarif chce navíc uložit kartu; bez ní obchod nevznikne, 30 dní je zdarma a první platba přijde 31. den. Nástroj nic neúčtuje a neposílá žádný e-mail. Průběh sleduj nástrojem shopzi_store_creation_status. API klíč k novému obchodu se v terminálu nikdy neobjeví, ukáže se jednou v prohlížeči.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | Tarif z `shopzi_list_plans`. `free` = obchod zdarma bez platební karty; placené tarify chtějí kartu (30 dní zdarma). | |
| interval | Yes | Měsíční (`monthly`), nebo roční (`annual`) platba. U tarifu `free` na hodnotě nezáleží. | |
| shop_name | Yes | Název obchodu, jak ho uvidí zákazníci. | |
| subdomain | Yes | Subdoména obchodu. Ověř ji napřed nástrojem `shopzi_check_subdomain`. |
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| currency | Yes | |
| interval | Yes | |
| shop_url | Yes | Adresa, na které obchod poběží (u placeného tarifu po uložení platební karty). |
| draft_url | Yes | Odkaz, který člověk otevře v prohlížeči. Dokončí v něm e-mail, podmínky a u placeného tarifu uložení karty. |
| plan_name | Yes | Český název tarifu z ceníku (`plan` je jen identifikátor). Pod tímhle názvem tarif zná člověk, který obchod zakládá. |
| shop_name | Yes | |
| subdomain | Yes | |
| expires_at | Yes | Kdy koncept vyprší, když se nedokončí (ISO 8601). |
| next_steps | Yes | |
| price_minor | Yes | Cena tarifu za zvolenou periodu v haléřích (u `free` 0). Teď se neplatí nic: u placeného tarifu je prvních 30 dní zdarma a tuhle částku Stripe vyfakturuje 31. den. |
| pairing_code | Yes | Kód, který člověk zadá v prohlížeči. Ukaž mu ho, stránka ho sama nezobrazí. |
| status_token | Yes | Token pro `shopzi_store_creation_status`. Není to API klíč a nic neotevírá. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides rich behavioral context beyond annotations: the tool only creates a draft (no store yet), requires browser interaction, does not charge or send email, explains free vs paid plan differences (30-day trial, card required), and states the API key appears only in the browser, never in the terminal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and is well-structured. It is somewhat dense but every sentence adds value (draft flow, plan details, no charges, tracking tool, API key handling). Could be marginally tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the multi-step creation flow, output schema presence, and annotations, the description covers all critical behavioral aspects an agent needs: it is a draft, requires human browser steps, no immediate charges, plan-specific billing behavior, and how to track progress.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters in detail. The description adds little parameter-specific meaning beyond noting plan types, which is also in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Založí KONCEPT nového obchodu a podrží pro něj subdoménu.' It explicitly distinguishes this draft-creation step from the later actual store creation, and names the sibling tool `shopzi_store_creation_status` for progress tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the flow clearly: a human must open `draft_url`, enter `pairing_code`, verify email, etc. It names `shopzi_store_creation_status` as the tracking tool, but does not explicitly mention `shopzi_check_subdomain` (that is only in the schema) or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hledá a čte oficiální českou dokumentaci SHOPZI, návody k administraci i dokumentaci pro vývojáře (fulltextově, zdarma). mode: "search" s query vrátí nejvýš 8 úryvků, mode: "read" se slug z hledání vrátí článek nebo jeho kapitolu. Použij ho, když se člověk ptá, jak se v SHOPZI něco dělá nebo jak se k obchodu připojit.
| Name | Required | Description | Default |
|---|---|---|---|
| docs | No | Jen u `search`: `uzivatele` = návody k administraci, `vyvojari` = dokumentace pro vývojáře. Vynechané = obě. | |
| mode | Yes | search = najít v návodech (vyžaduje `query`); read = přečíst článek (vyžaduje `slug`). | |
| slug | No | Jen u `read`: identifikátor článku z hledání. | |
| query | No | Jen u `search`: otázka vlastními slovy. | |
| heading | No | Jen u `read`: název kapitoly (H2), když stačí její část. Neznámý název vrátí jen nadpisy. | |
| section | No | Jen u `search`: zúží hledání na jednu sekci dokumentace. |
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| note | Yes | |
| article | Yes | |
| suggestions | Yes | |
| lexical_only | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral detail beyond that: fulltext search returns at most 8 snippets, and read consumes a slug obtained from a prior search and can return a whole article or just a chapter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it is, how the two modes behave, when to reach for it. The capability statement and the 8-snippet limit are front-loaded with no wasted clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the description covers the search-then-read workflow and the when-to-use condition. Only the search→read dependency is implied rather than spelled out as a required two-step sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; every parameter including enums and the heading fallback is documented in the schema. The description restates the mode/query and mode/slug pairing but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair (hledá a čte) plus the exact resource (oficiální česká dokumentace SHOPZI, administrace i vývojáři) and names both operating modes. No sibling touches documentation, so the agent can immediately tell this is the docs-lookup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger: use it when a person asks how something is done in SHOPZI or how to connect a store. It does not explicitly exclude adjacent needs (plans, store creation, subdomain checks) handled by the siblings, but the trigger condition is clear enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vrátí tarify, které jde založit přes MCP: Free zdarma bez karty a placené tarify s cenou za měsíc i za rok v haléřích přímo ze Stripe, vše s limity tarifu. WEBZI s.r.o. není plátcem DPH, ceny jsou konečné. Placený obchod založený přes MCP má 30 dní zdarma stejně jako obchod z webu: kartu člověk uloží v prohlížeči při zakládání, nic se z ní nestrhne a první platba přijde 31. den.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plans | Yes | |
| currency | Yes | |
| vat_note | Yes | |
| trial_note | Yes | |
| prices_checked_at | Yes | Kdy se ceny naposledy ověřily ve Stripe (ISO 8601). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real domain context beyond annotations: prices come from Stripe in haléře, the vendor is not a VAT payer so prices are final, and the 30-day free trial with first charge on day 31. It does not say whether the plan list is static or region-dependent, but the added pricing semantics are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first clause, and the follow-on sentences about currency units, VAT and the trial period each carry information an agent may need to relay to a user. It is dense but not padded; the trial/payment paragraph is arguably commercial detail that could be trimmed for a pure listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and no input parameters, the description only needed to frame the resource and any non-obvious semantics of the returned data; it does both, covering plan tiers, price units, tax treatment and the trial-charging behaviour. Nothing required to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly spends no text on inputs and instead explains the semantics of the returned price values (haléře, final prices including VAT treatment).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause states a specific verb and resource: it returns the tariffs/plans that can be set up via MCP, and specifies whether each is free or paid with monthly and yearly pricing. No sibling tool (check_subdomain, create_store, docs, store_creation_status) overlaps with plan listing, so an agent can route unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: because it returns plans 'that can be set up via MCP', an agent can infer it should be called before shopzi_create_store to learn pricing. There is no explicit statement of when to call it, no mention of prerequisites, and no reference to any sibling as an alternative or follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Řekne, kde zakládání obchodu je: čeká na prohlížeč, na uložení karty, zakládá se, je hotovo, nebo potřebuje podporu. Po dokončení vrátí adresu obchodu a přihlášení do administrace, nikdy klíč ani přihlašovací token.
| Name | Required | Description | Default |
|---|---|---|---|
| status_token | Yes | `status_token` z výsledku `shopzi_create_store`. |
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| status | Yes | |
| message | Yes | Co se právě děje a co má člověk udělat, česky. |
| interval | Yes | |
| shop_url | Yes | Adresa obchodu, jakmile existuje. Jinak `null`. |
| admin_url | Yes | Přihlášení do administrace, jakmile obchod existuje. Obyčejná adresa, žádný token. |
| plan_name | Yes | Český název tarifu z ceníku (`plan` je jen identifikátor). Pod tímhle názvem tarif zná člověk, který obchod zakládá. |
| shop_name | Yes | |
| subdomain | Yes | |
| expires_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description's real contribution is the disclosure that the result includes the store address and admin login but never the key or login token, plus the existence of a 'needs support' terminal state. That is meaningful security and outcome context beyond the structured fields, though it says nothing about error cases or expiry of the token.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the state enumeration and followed by the security-relevant return promise. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain the return shape, and it still flags the key contents. For a one-parameter polling tool this is nearly complete; only polling cadence and terminal-state handling are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, and the schema already states it is taken from the shopzi_create_store result. The description adds no further meaning about the token (validity, lifetime, reuse), so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (store creation status) and enumerates the concrete states it reports: waiting for browser, waiting for card save, creating, done, needs support. That makes the tool easy to tell apart from siblings in practice, but it never explicitly contrasts itself with shopzi_create_store, which is where the status_token originates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the state list suggests polling during an in-progress creation flow, and the schema notes the token comes from shopzi_create_store. The description itself gives no explicit when-to-use, when-not-to-use, or polling guidance (e.g., how often to call, whether to stop after a terminal state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
shopzi_create_store7 fields changedInput schema / properties / interval / descriptionPrevious value: -"Měsíční (`monthly`), nebo roční (`annual`) platba."New value: +"Měsíční (`monthly`), nebo roční (`annual`) platba. U tarifu `free` na hodnotě nezáleží."Input schema / properties / plan / descriptionPrevious value: -"Tarif z `shopzi_list_plans`. Přes MCP jde založit jen placený tarif."New value: +"Tarif z `shopzi_list_plans`. `free` = obchod zdarma bez platební karty; placené tarify chtějí kartu (30 dní zdarma)."Input schema / properties / plan / enumPrevious value: -[
- "start",
- "growth",
- "scale",
- "pro"
-]New value: +[
+ "free",
+ "start",
+ "growth",
+ "scale",
+ "pro"
+]Output schema / properties / draft_url / descriptionPrevious value: -"Odkaz, který člověk otevře v prohlížeči. Dokončí v něm e-mail, podmínky a platbu."New value: +"Odkaz, který člověk otevře v prohlížeči. Dokončí v něm e-mail, podmínky a u placeného tarifu uložení karty."Output schema / properties / plan / enumPrevious value: -[
- "start",
- "growth",
- "scale",
- "pro"
-]New value: +[
+ "free",
+ "start",
+ "growth",
+ "scale",
+ "pro"
+]Output schema / properties / price_minor / descriptionPrevious value: -"Cena tarifu za zvolenou periodu v haléřích. Teď se neplatí nic: prvních 30 dní je zdarma a tuhle částku Stripe vyfakturuje 31. den."New value: +"Cena tarifu za zvolenou periodu v haléřích (u `free` 0). Teď se neplatí nic: u placeného tarifu je prvních 30 dní zdarma a tuhle částku Stripe vyfakturuje 31. den."Output schema / properties / shop_url / descriptionPrevious value: -"Adresa, na které obchod poběží po uložení platební karty."New value: +"Adresa, na které obchod poběží (u placeného tarifu po uložení platební karty)."shopzi_list_plans1 field changedOutput schema / properties / plans / items / properties / plan / enumPrevious value: -[
- "start",
- "growth",
- "scale",
- "pro"
-]New value: +[
+ "free",
+ "start",
+ "growth",
+ "scale",
+ "pro"
+]shopzi_store_creation_status1 field changedOutput schema / properties / plan / enumPrevious value: -[
- "start",
- "growth",
- "scale",
- "pro"
-]New value: +[
+ "free",
+ "start",
+ "growth",
+ "scale",
+ "pro"
+]shopzi_check_subdomainshopzi_create_storeshopzi_docsshopzi_list_plansshopzi_store_creation_statusizHost public read-only MCP: service pricing and live domain availability lookup.
Search ~8.5M products from 2,500+ Central European e-shops. Semantic, keyword, GTIN lookup.
Your online store: products, stock, orders, customers and payments into your own account.
Your online store: products, stock, orders, customers and payments into your own account.
Add one secure layer between your agents and this server.
