drukarnia

Server Details

BARWA print shop (barwa.pl): catalog, product advisor, real-price quotes, shipping, file specs.

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: 99.6% over 56 days
Last Tested: 2026-10-14 20:54
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-09-21 18:10 across 6 tools

Disambiguation5/5

Each tool maps to a distinct step in the print-shop workflow: product discovery, recommendation, pricing options, price quote, shipping, and file preparation. The get_product_pricing_schema/get_quote pair is clearly separated as 'valid input options' vs 'actual calculated price', so an agent is unlikely to confuse them.

Naming Consistency5/5

All tool names follow a consistent snake_case verb-first pattern: get_* for data lookups, list_* for catalog enumeration, and recommend_* for the recommendation action. The object nouns are specific and the pattern makes new tool usage predictable.

Tool Count5/5

Six tools is well within the ideal scope and each one fills a necessary role without redundancy. The count is large enough to cover the quoting flow end-to-end but small enough to avoid overwhelming an agent.

Completeness4/5

The set covers the full pre-sales workflow: browse, recommend, validate options, quote, shipping, and file specs, with no dead ends between tools. It lacks an explicit order/checkout tool and a direct single-product detail endpoint, but those appear outside the server's stated quote-focused scope and links/workarounds are available.

Available Tools

6 tools

get_file_specsAInspect

Get print-file preparation requirements for a barwa.pl product (format, color mode, resolution, bleed) plus a link to the how-to-prepare guide. The ai_generation section gives exact pixel dimensions (bleed included, 300 DPI) for AI image generators — pass width_mm/height_mm (trim size in millimeters) to get pixel dimensions for a custom size.

ParametersJSON Schema

Name	Required	Description	Default
`width_mm`	No
`height_mm`	No
`product_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden. It explains what the tool returns and how width_mm/height_mm affect pixel dimensions, but it does not explicitly state that this is a read-only operation, mention authentication prerequisites, or address invalid inputs. This is a partial disclosure.

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 primary purpose, and the second sentence adds a specific use case (AI image generation) without redundancy. Every word 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?

The description covers the main purpose, a special feature (ai_generation), and parameter behavior. Since an output schema exists, return values need not be detailed. Minor gaps include prerequisites and error conditions, but overall it's sufficient for an AI agent to decide invocation.

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 0%, so the description must compensate. It explains width_mm and height_mm as trim size in millimeters used to compute custom pixel dimensions, which adds value. However, product_slug is not explicitly described, though it is implied by 'barwa.pl product'. Partial compensation.

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 verb 'Get' and the resource 'print-file preparation requirements for a barwa.pl product', specifying format, color mode, resolution, bleed. This distinguishes it from sibling tools like get_quote or list_products.

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 clear context for when to use the tool — when print-file specs or AI-generator pixel dimensions are needed. It doesn't explicitly exclude alternatives, but the sibling tools have distinct purposes, so the context is sufficient.

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

get_product_pricing_schemaAInspect

Get the full set of quotable parameters for a barwa.pl product: allowed sizes/formats, quantity limits, materials, single/double-sided option, page-count limits and available finishes (marking which are mandatory). Call before get_quote to know valid option ids.

ParametersJSON Schema

Name	Required	Description	Default
`product_slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It describes that the tool returns a full set of quotable parameters, including mandatory finishes. It is transparent about the output without mentioning side effects or auth, which is acceptable for a schema retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is two sentences, with the main purpose upfront ('Get the full set...') followed by specific details. Every sentence adds value, no fluff.

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?

Given one input parameter and an output schema (not shown), the description covers what the tool returns and when to use it. It could be improved by mentioning that product_slug should be a valid slug, but for a schema retrieval, it is mostly complete.

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 parameter product_slug is not described in the schema (0% coverage) and the description only indirectly implies it's a product identifier. It does not give examples or format, but the tool name and purpose provide enough context for a single parameter. Baseline 3 for single param with no schema 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 verb 'get' and the resource 'product pricing schema'. It lists specific contents like sizes, quantity limits, materials, etc., and distinguishes from sibling tools by noting it should be called before get_quote, differentiating it from get_quote, get_file_specs, and others.

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 explicitly says 'Call before get_quote to know valid option ids', providing clear usage context. It implies when to use it but does not explicitly mention when not to use it or list alternatives, but the context from siblings is sufficient.

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

get_quoteInspect

Get a price quote for a barwa.pl product. Calculated by the same engine as the on-site calculator, so the price is identical. Returns net/gross price, currency, delivery time and, if the configuration matches a defined product, its name and link. Use get_product_pricing_schema first for valid option ids. width/height in mm (free-size products) or format_id (predefined). quantity is the TOTAL run and the product minimum applies per design: with liczba_wzorow=N the minimum is N x schema quantity.min. pages = total inner pages/sheets (books, brochures, calendars) — only when the schema lists options.pages; respect its min/max/step. A product whose schema marks material as required (no default) needs material_id. Bound products (books, brochures, notebooks) need a quantity that is a multiple of copies per sheet, which depends on size and material: on error quantity_not_multiple retry with a value from allowed.quantities. Default finishes are already included; to drop one (e.g. no lamination) pass its group_id in remove_finish_groups (only groups with removable=true) and relay any returned warnings to the customer.

ParametersJSON Schema

Name	Required	Description	Default
`pages`	No
`width`	No
`height`	No
`finishes`	No
`quantity`	Yes
`format_id`	No
`material_id`	No
`double_sided`	No
`product_slug`	Yes
`liczba_wzorow`	No
`remove_finish_groups`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

get_shipping_infoAInspect

Get shipping cost thresholds (by order weight) and the free-shipping threshold for the shop's country, in the shop currency.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are present, but the description clearly states what data is returned (thresholds and free-shipping with context). For a read-only tool with no side effects, this is sufficient transparency.

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 a single, clear sentence with no unnecessary words. It is perfectly concise and 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?

With no parameters and an existing output schema (implied), the description fully specifies what the tool returns. No additional context is needed given the tool's simplicity.

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?

There are zero parameters, so the baseline is 4. The description adds value by explaining the output, which goes beyond the empty input schema.

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 explicitly states it retrieves shipping cost thresholds based on order weight and the free-shipping threshold, all in the shop's country and currency. This is specific and distinct from sibling tools which deal with files, pricing, quotes, products, and recommendations.

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?

No explicit usage guidance or alternatives are provided. However, the tool's purpose is straightforward with no parameters, making when to use it self-evident. The lack of explicit direction keeps this at a 3.

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

list_productsAInspect

List printing products available at the barwa.pl online print shop (business cards, flyers, posters, stickers, books, etc.) with links. Prices are obtained per product via get_quote — call that with a product's slug.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided; the description describes a simple list operation with no destructive actions. It could be improved by stating read-only or authentication requirements, but the current description is adequate.

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 purpose, no extraneous words. Every sentence adds value.

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 parameterless list tool with an output schema, the description covers the purpose and cross-references the pricing tool, making it complete.

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?

No parameters exist, so the baseline is 4. The description adds no parameter info, which is acceptable since there are none.

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 lists printing products from a specific shop, with examples, and distinguishes from sibling tools like get_quote which handles pricing.

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?

Explicitly mentions when to use this tool (to list products) and directs the agent to use get_quote for pricing, including the required slug parameter.

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

recommend_productAInspect

Recommend barwa.pl products matching a described customer need (e.g. "something for a trade fair", "gift packaging"). Returns matching products with links; price them with get_quote. If empty, ask the customer to clarify the need.

ParametersJSON Schema

Name	Required	Description	Default
`purpose`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns products with links and directs pricing to get_quote. It also instructs on handling empty results. For a recommendation tool, this sufficiently covers behavioral traits.

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 extremely concise with two sentences. It front-loads the core purpose and adds necessary guidance without any wasted words.

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?

Given the presence of an output schema (not shown), the description does not need to detail return values. It covers the essential behavior: recommending products, mentioning links, and referencing pricing. The instruction for empty results adds completeness. The tool is simple enough that this is adequate.

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 single parameter 'purpose' has no description in the schema (0% coverage). The description adds meaning by providing examples of needs ('trade fair', 'gift packaging') and implies it is a free-text customer need. This adequately compensates for the schema gap.

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 uses a specific verb 'Recommend' and clearly identifies the resource 'barwa.pl products'. It provides concrete examples ('something for a trade fair', 'gift packaging') that distinguish it from sibling tools like list_products 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 states when to use the tool (to match a customer need) and what to do if no results (ask for clarification). It also references a related tool (get_quote) for pricing. However, it does not explicitly exclude scenarios or mention alternatives.

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

Tool Schema Changelog

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

1 tool updateOct 13, 2026

Changedget_quote1 field changed

addedInput schema / properties / remove_finish_groups

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "integer"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

1 tool updateJul 31, 2026

Changedget_file_specs2 fields changed

addedInput schema / properties / height_mm

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

addedInput schema / properties / width_mm

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

6 tool updatesJul 16, 2026
- First observedget_file_specs
- First observedget_product_pricing_schema
- First observedget_quote
- First observedget_shipping_info
- First observedlist_products
- First observedrecommend_product

Related MCP Connectors

Denia Print A
es.deniaprint
Print shop in Spain: products, exact prices, quote requests and order status for AI assistants
E-commerce & Retail
81
Fulfiller — print catalogue & quotes A
com.fulfiller
Print catalogue and live quotes from Fulfiller, a French online printer shipping across the EU.
E-commerce & Retail
111
bitvisual-mcp
br.com.bitvisual
Agent-ready print shop in Sao Paulo: catalog, official BRL quotes per m2, shipping, PIX orders.
61
Dinilu — custom promotional products A
eu.dinilu
Live prices, options and shipping quotes for custom-printed promotional products.
E-commerce & Retail Marketing
51

Related MCP Servers

Poland
Government Data Legal & Compliance
Xopoko
A
license
Not graded
quality
A
maintenance
Your AI agent's practical guide to life and administration in Poland.
Updated a month ago (2026-09-05 12:35 UTC)
MIT
fakturka-api-mcp
Finance Government Data
softvoyagers
A
license
Not graded
quality
F
maintenance
Free Polish VAT invoice generation MCP server with PDF output and preview. No API key required.
Updated 6 months ago (2026-04-09 08:45 UTC)
30 npm
1
MIT
cenogram-mcp-serverofficial
Government Data Real Estate
cenogram
A
license
A
quality
A
maintenance
7M+ real estate transactions from Poland's RCN registry. Search, compare, and analyze prices
Updated 19 days ago (2026-09-25 21:53 UTC)
28
77 npm
1
MIT
Shoptera Product Intelligenceofficial
E-commerce & Retail Search
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)
Updated 6 months ago (2026-04-15 13:49 UTC)
MIT