Potisk triček a textilu na míru (ČR) — katalog, ceny, příprava designu a objednávky.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 5 of 5 tools scored.
Each tool targets a distinct resource or workflow step: product catalog (list_products), price estimation (get_quote), design creation (create_design), order placement (create_order), and status tracking (get_order_status). The pricing overlap between create_design and get_quote is resolved by clear descriptions: one validates and saves a design with an estimated print cost, the other calculates a full shirt quote independently.
All tool names follow a consistent verb_noun pattern: create_ for creation, get_ for retrieval, and list_ for listing. There are no mixed conventions or vague verbs, making the naming predictable and easy to navigate.
Five tools is well-sized for the server's purpose as a custom apparel configurator. It covers the essential steps—product browsing, quoting, design, ordering, and status—without redundancy or unnecessary bulk.
The tools provide a complete ordering flow: discover products, get a quote, create a design, place an order, and check status. Minor gaps exist, such as no design management (list/update/delete) or order cancellation, but these are not critical to the core configuration and ordering workflow.
create_designAInspectZvaliduje a uloží design (logo/text na stranách trička) a vrátí orientační cenu potisku + vrstvy s nahranými URL k použití v create_order.
| Name | Required | Description | Default |
|---|---|---|---|
| layers | Yes | 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?} | |
| colorId | No | ||
| product | Yes | ||
| previewBackDataUrl | No | ||
| previewFrontDataUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and idempotentHint=false, and the description adds that the tool validates and saves a design, indicating a persistent side effect. It also discloses that it returns an indicative price and layers with uploaded URLs, which is useful behavioral context beyond the annotations. No contradiction found.
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 description is a single, front-loaded sentence that efficiently states the action, object, and result without redundancy. Every clause adds information: validation, saving, the design scope, and the returned data for create_order.
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?
The description covers the overall purpose and return value (price and layers), but with 5 parameters and no output schema, the absence of parameter explanations and edge cases leaves gaps. It does not mention required fields (product, layers) or the meaning of preview data URLs, so while the main context is clear, it is not fully complete for a tool of this complexity.
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 only 20% (only 'layers' has a description). The top-level description mentions 'logo/text on t-shirt sides' which loosely relates to the 'layers' parameter but does not explain `colorId`, `product`, `previewBackDataUrl`, or `previewFrontDataUrl`. With such low coverage, the description fails to compensate for the undocumented parameters.
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 clearly states the tool validates and saves a design (logo/text on t-shirt sides) and returns an indicative price plus layers for use in create_order. This distinguishes it from siblings like create_order (which places the order) and get_quote (which presumably only quotes) by specifying the resource (design) and the output (prepared layers with URLs).
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?
The description implies the tool is a precursor to create_order by stating the result is for use in create_order, giving clear context for when to use it. However, it does not explicitly say when not to use it or name alternatives (e.g., use get_quote for price-only queries), so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_orderAInspectZaloží objednávku (čeká na platbu) a vrátí platební instrukce: částku, číslo účtu, variabilní symbol a QR. Platí člověk převodem — agent neplatí. Vyžaduje customer.email a consent:true.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | položky: {product (id/slug), colorId?, colorName?, size, quantity, printMethod?, layers? (z create_design)} | |
| notes | No | 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 | |
| consent | Yes | souhlas s obchodními podmínkami, musí být true | |
| customer | Yes | {email (povinné), name?, phone?, address?, companyName?, ico?, dic?, billingStreet?, billingCity?, billingZip?, billingCountry?} | |
| promoCode | No | ||
| shippingId | No | např. 'zasilkovna','balikovna','ppl','dpd' (volitelné) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint false, idempotentHint false), the description adds important behavioral context: the order is created but payment is deferred, the agent does not pay, and the tool returns specific payment instructions. This is valuable and does not contradict any 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?
The description is compact and front-loaded: the first sentence states the main action and return value, the second adds payment behavior and requirements. There is no redundant or filler content.
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?
The description covers the core workflow, required fields, and return payload well enough for an agent to invoke the tool correctly. It does not explicitly mention returning an order ID for later status lookups, but the payment instructions are clearly enumerated, so this is a minor gap rather than a major omission.
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 high (83%), so the schema already explains most parameters. The description reinforces that customer.email and consent:true are required, but it adds little semantic detail beyond what the schema already states. This matches the baseline of 3 for well-covered schemas.
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 clearly states the tool creates an order ('Založí objednávku') and returns payment instructions, which distinguishes it from siblings like create_design, get_quote, and get_order_status. The verb and resource are specific, and the scope is unambiguous.
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?
The description gives clear context: it creates an order awaiting payment, requires consent, and clarifies that the human pays by bank transfer rather than the agent. It does not explicitly name alternatives or state when not to use the tool, so it stops slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_order_statusAVrátí stav objednávky (stav platby a zpracování) podle čísla objednávky.
| Name | Required | Description | Default |
|---|---|---|---|
| orderNumber | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the status includes payment and processing details, which is useful context, but it doesn't explain error behaviors or return format.
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 description is a single, focused sentence that immediately states the function and the key parameter, with no extraneous words.
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?
For a simple read-only tool with one parameter and no output schema, the description provides enough information: what it returns and how to identify the order. It doesn't need to list all possible statuses given the tool's low complexity.
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 schema only defines orderNumber as a string with no description. The description compensates by indicating that 'podle čísla objednávky' means the order number is the lookup key, giving semantic meaning.
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 states a specific verb 'Vrátí' (returns) and a clear resource: order status, further specifying it includes payment and processing status. This distinguishes it from sibling tools like create_order and get_quote.
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?
The description clearly implies this tool is for checking order status based on order number. While it doesn't explicitly name alternatives, the context is unambiguous and no exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quoteASpočítá cenu nakonfigurovaného trička (vč. DPH) — podle množství/velikostí, počtu potištěných stran a promo kódu.
| Name | Required | Description | Default |
|---|---|---|---|
| sizes | No | mapování velikost→počet, např. {"M":10,"L":5} | |
| product | Yes | ||
| quantity | No | ||
| promoCode | No | ||
| printedSides | No | počet potištěných stran 0–4 | |
| printSideHeightsCm | No | výška motivu v cm na každé potištěné straně |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the price includes VAT, which is useful behavioral context, but it does not disclose return format, error cases, or any other operational details.
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 description is a single sentence, front-loaded with the verb and purpose, with no redundant information. It efficiently conveys the core behavior.
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 no output schema, the description should ideally convey what the tool returns, but it only states the pricing function. Given the read-only annotation and clear purpose, it is minimally complete, but the omission of printSideHeightsCm and the required product parameter leaves gaps for an agent trying to invoke it correctly.
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 only 50%, and the description should compensate for undocumented parameters. It mentions quantity/sizes, printed sides, and promo code, but omits the required product parameter and printSideHeightsCm. For the parameters it does mention, it adds little beyond the schema, leaving key semantics unexplained.
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 clearly states the tool calculates the price of a configured T-shirt including VAT, distinguishing it from siblings like create_order or get_order_status. The verb 'Spočítá' (calculates) and resource 'cenu nakonfigurovaného trička' are specific and unambiguous.
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?
The description provides clear context for when to use the tool: when pricing a configured T-shirt before placing an order. It does not explicitly state exclusions or alternatives, but the sibling tool names and the read-only nature make the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsAVrátí katalog triček/mikin Suorigo (barvy, velikosti, ceny vč. množstevních slev) nebo jeden produkt podle id/slug.
| Name | Required | Description | Default |
|---|---|---|---|
| product | No | id nebo slug konkrétního produktu (volitelné) |
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.
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.
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.
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.
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.
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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
