Skip to main content
Glama
Sign In

ABC Remonty Oleba

by pl.oleba
OverviewDiscussionsAdmin

Oleba — kalkulator usług remontowych

get_renovation_calculator
Read-onlyIdempotent

Open the interactive Oleba calculator: all 14 price-list categories, including plaster, drywall, tiles, bathroom fittings, flooring, electrical, plumbing, demolition, apartment renovation, developer finishing, decorative work, general work and mezzanines. Empty lines open the form. Call once without lines to obtain current catalog and stable service_id values; never invent IDs or prices. Quantity unit is supplied by catalog: m² of treated surface (apartment and developer categories use floor area), mb length, szt./pkt./moduł integer count. Lines may mix categories; each category is resolved from its current service_id. The top-level category only selects the initial form category. Apartment and developer allow ONE complete package, never add its included bathroom/installations again. Multiple itemised lines are allowed only when user confirms the scopes do not overlap (separate_scopes_confirmed). Prices from current public cennik; ambiguous/from/individual prices are not calculated. Labour only, no materials or inferred tax. Read-only, no booking or WordPress edits. If MCP Apps UI is unavailable, call this same tool with confirmed quantities and show the returned estimate as text: services, quantities, units, rates, labour total and assumptions. Ask for missing inputs. Never claim that UI was displayed. For clients without MCP, offer the public HTML calculator: https://oleba.pl/?oleba_calculator=1

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_renovation_calculator"
  }
}

Input Schema

NameRequiredDescriptionDefault
linesNo
categoryNoInitial form category (default tiles). Does not restrict lines: each service_id determines its category.
separate_scopes_confirmedNoTrue only after user confirms the selected lines represent separate non-overlapping work. Required for two or more lines.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / category / description
      Previous value: -"Default tiles; switching category starts a separate estimate."New value: +"Initial form category (default tiles). Does not restrict lines: each service_id determines its category."
  2. Changed1 schema field changed
    • changedInput schema / properties / category / enum
      Previous value: -[
-  "painting",
-  "tiles",
-  "apartment",
-  "electrical",
-  "plumbing"
-]New value: +[
+  "painting",
+  "plaster",
+  "drywall",
+  "tiles",
+  "bathroom_fittings",
+  "flooring",
+  "electrical",
+  "plumbing",
+  "demolition",
+  "apartment",
+  "developer",
+  "decorative",
+  "general",
+  "mezzanine"
+]
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare read-only, idempotent, closed-world safety; the description adds real behavioral context: never invent IDs or prices, labour-only pricing with no materials or inferred tax, package rules for apartment/developer categories, and the instruction never to claim the UI was displayed. It also supplies a non-MCP fallback URL, which no annotation conveys.

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?

Front-loads the purpose and the catalog-call instruction, and nearly every sentence carries operational information. It is nonetheless a dense, run-on block of roughly a dozen clauses with minor redundancy (restating read-only, which annotations already declare), which slightly taxes scanning.

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?

Despite having no output schema, the description enumerates what the text-mode estimate contains (services, quantities, units, rates, labour total, assumptions), covers input-gathering ('Ask for missing inputs'), and defines the no-UI and no-MCP paths. Nothing an agent needs to invoke it correctly is left unstated.

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

Parameters5/5

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

With 67% schema coverage, the description carries the missing meaning: quantities use units supplied by the catalog (m² of treated surface, floor area for apartment/developer, mb length, integer szt./pkt./moduł), and it warns that mixing units across categories is possible. It explains that category only selects the initial form category and does not restrict lines, and that separate_scopes_confirmed is required for two or more lines.

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?

States a specific verb and resource: it opens an interactive renovation calculator covering 'all 14 price-list categories' and, in text mode, returns an estimate. The breadth statement implicitly separates it from the narrower get_paint_calculator sibling, but no sibling is named explicitly, so an agent must infer the boundary against get_prices, get_price_information and ask_oleba.

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?

Gives explicit invocation modes: call empty to obtain the catalog and stable service_id values, call with lines to price work, and fall back to 'confirmed quantities and show the returned estimate as text' when MCP Apps UI is unavailable. It also names the condition for multi-line use (separate_scopes_confirmed, user confirmation that scopes do not overlap) and the excluded cases (ambiguous, 'from' or individual prices are not calculated).

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

All ABC Remonty Oleba toolsInspect
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