Editorial fair prices for products in Poland, plus a Polish net salary and tax calculator.
Scored across 4 tools
The four tools are clearly distinct: one calculator for Polish income comparison, and three complementary Fair Price tools (history, product details, product list). No two tools overlap in purpose.
Three tools follow a clear verb_polish_fair_price_noun pattern, but calculate_polish_income_comparison is an outlier with a different noun pattern and is overly long. The overall convention is still predictable.
Four tools is a bit thin but reasonable for a niche server covering two small domains. It avoids bloat and each tool earns its place.
The income comparison tool covers multiple Polish contract types comprehensively, and the Fair Price tools provide list/get/history coverage. Minor gaps include no explicit create/update for price estimates or detailed tax breakdown retrieval.
Calculate Polish contract and tax net income comparison for a company budget or UoP gross across UoP (employment), Umowa Zlecenie (mandate), Umowa o Dzieło (work contract), B2B (progressive, linear 19%, lump-sum/ryczałt), and Spółka z o.o. (board member resolution).
| Name | Required | Description | Default |
|---|---|---|---|
| zus | No | B2B ZUS type: standard, preferential, or start. | standard |
| costs | No | Monthly business operating costs in PLN for B2B. | |
| budget | No | Total monthly company employer budget in PLN (e.g. 15000). | |
| grossUop | No | Gross employment contract salary if inputMode is uop_gross. | |
| llcCosts | No | Monthly accounting and operating costs in PLN for Spółka z o.o. (default 600 PLN). | |
| lumpRate | No | B2B lump sum tax rate percentage if taxation is lump (e.g. 12, 15, 8.5). | |
| taxation | No | B2B taxation type: progressive, linear, or lump. | progressive |
| inputMode | No | Input mode: budget (total employer cost) or uop_gross (gross employment contract). | budget |
| uopUnder26 | No | Whether the employment (UoP) employee is under 26 (exempt from PIT up to limit). | |
| studentUnder26 | No | Whether the mandate contractor is a student under 26 (exempt from ZUS and PIT up to limit). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, closed-world computation. The description usefully adds the tax-regime scope (progressive, linear 19%, lump-sum/ryczałt) and the resolution basis for Spółka z o.o. However, it discloses nothing about the calculation's assumptions (which year's ZUS/PIT rates) or output shape, which the annotations do not cover.
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?
A single front-loaded sentence with the verb first and no filler. It is dense because of the many parenthetical Polish terms, but every clause maps to a real contract type the tool handles. No wasted sentences.
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 10-parameter tax/calculation tool with no output schema, the description identifies what is computed and across which contract types but omits the return structure, the rate-year assumptions, and how inputMode changes the result. With 100% schema coverage the parameter side is covered, so the remaining gap is output/assumption disclosure, leaving it adequate but incomplete.
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% (10 params, 0 required), so the schema already documents zus, costs, budget, grossUop, taxation, inputMode, and the under-26 flags. The description only tangentially reinforces parameter meaning (taxation variants, contract types) without adding syntax or modes beyond the schema. Baseline 3 applies when the schema carries the load.
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 verb (Calculate) and resource (Polish contract and tax net income comparison) and enumerates the contract types it covers (UoP, Umowa Zlecenie, Umowa Dzieło, B2B, Spółka z o.o.). The purpose is recognizably a multi-contract net-income comparison, but the run-on phrasing mixing 'contract and tax net income comparison for a company budget or UoP gross' is slightly dense. Siblings are all fair-price tools, so no differentiation is needed.
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?
There is no explicit when-to-use or when-not-to-use statement and no named alternative. The phrase 'for a company budget or UoP gross' hints at input scenarios but is really parameter framing, not usage guidance. The agent gets no signal about when this comparison is the right tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dated personal estimates of what Bahdan Hal would pay for an exact product in Poland.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug returned by list_polish_fair_price_products. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, closed-domain read. The description adds the useful prerequisite that it operates on an 'exact product', matching the slug requirement, but says nothing about the shape, span, or pagination of the dated series it returns.
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?
A single sentence that front-loads the verb and the resource with zero filler. Nothing could be trimmed without losing meaning.
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 one-parameter read-only tool with full schema coverage and no output schema, the description is minimally sufficient. It is missing any indication of what the returned history looks like (dates, amounts, unit or currency), which the absent output schema leaves entirely to inference.
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 single slug parameter is fully documented in the schema, including its provenance from list_polish_fair_price_products. The description adds only the qualifier 'exact product', so the schema is doing the heavy lifting and baseline 3 is appropriate.
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 concrete verb ('Get') and resource ('dated personal estimates of what Bahdan Hal would pay'), so the agent knows this returns a historical series rather than a single value. It separates itself implicitly from get_polish_fair_price_product via 'dated' and 'history', but it never names that sibling, so the differentiation is left to inference.
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?
There is no when-to-use statement and no exclusions. The word 'history' hints at a trend-over-time use case, but the description never says when to prefer this over get_polish_fair_price_product (the current estimate) or list_polish_fair_price_products, which is the key routing decision an agent faces here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full product specification, family grouping, and media details for a product slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug returned by list_polish_fair_price_products. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only that the response bundles specification, family grouping, and media; it says nothing about behavior for an unknown slug, error handling, or payload size. Adequate against the lower annotated bar, but not rich.
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 front-loaded sentence that enumerates the returned content and contains no filler. Every clause earns its place.
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 must carry the return-value burden, and it does name the three returned categories. For a one-parameter read tool this is close to sufficient; it is only slightly thin on what 'family grouping' entails and on failure behavior for a bad slug.
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 required 'slug' parameter and schema coverage is 100%, with the schema itself explaining that the value comes from list_polish_fair_price_products. The description adds no format, casing, or validity constraints, so 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 names a specific verb (Get) and resource (product) and enumerates the payload: full specification, family grouping, and media details. The singular 'product slug' implicitly contrasts with the plural list_polish_fair_price_products sibling, but no sibling is named explicitly, so it stops short of a 5.
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 offers no when-to-use guidance, no prerequisites, and no routing between this tool and list_polish_fair_price_products or get_polish_fair_price_history. The only hint that a slug comes from the list tool lives in the input schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products with Bahdan Hal’s personal price estimates and dated history in Poland.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope closure are covered. The description adds only the data-source nuance ("Bahdan Hal's personal price estimates") and that results carry dated history; it says nothing about volume, ordering, or pagination of a list result.
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?
A single front-loaded sentence with no filler; the resource and its scope lead. Minor awkwardness in packing three distinct concepts (personal estimates, dated history, Poland) into one clause without separating them.
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 zero-parameter, no-output-schema list tool, the description conveys what the results are (personal price estimates with dated history) and the region. An agent has enough to call it, though ordering and result-size expectations remain unstated.
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 the baseline of 4 applies — there is nothing parameter-level the description could clarify. Schema description coverage is reported at 100% on an empty object.
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 ("List") and resource ("products") with a geographic scope ("in Poland") and the data contents ("personal price estimates and dated history"). It is clear, but it does not explicitly distinguish itself from siblings like get_polish_fair_price_product or get_polish_fair_price_history — the plural vs. singular distinction is left to inference.
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?
No when-to-use guidance is provided. It never says to prefer this tool over get_polish_fair_price_product for a single item, nor over get_polish_fair_price_history when history alone is wanted. The agent must infer the routing from the tool names alone.
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.
calculate_polish_income_comparisonget_polish_fair_price_historyget_polish_fair_price_productlist_polish_fair_price_productsSalaries in Poland from public job ads: occupations, cities, contract types, experience.
Search and compare Polish bank offers in real time. Find the best savings accounts, deposits, personal accounts, and business accounts. Browse active bank promotions with expert analysis of hidden fees and traps. Get referral codes for bonuses and calculate deposit interest with tax. 11 tools covering all Polish banking products.
Polish real-estate prices from notarial deeds: area stats, plot and building reports, valuations.
Read-only European tax, salary and benefit calculators with official sources and unknowns.
Add one secure layer between your agents and this server.
