Spanndecken ROTH Preisrechner

Stretch ceiling price estimate (Spanndecken ROTH)

calculate_spanndecken_price

Read-onlyIdempotent

Calculates a non-binding price estimate in EUR for a stretch ceiling (Spanndecke) from Spanndecken ROTH, Germany, with the same formula as the online calculator on spanndecken-roth.de. Only area_m2 (ceiling area in square metres) is required: the user may name just the area. Every other parameter is filled in server-side with a standard value when omitted — category A (lacquer / matt / satin), corners 4, spotlights 0, lamps 0, volume_discount false — and any value the user states overrides the standard value. The result repeats the parameters actually used and lists in defaults_applied which standard values were assumed, so tell the user about them. Surface categories: A = Lack / Matt / Satin with colour choice, B = Metallic / Exclusive / Galaxy, C = Fotodruck (photo print). Present the figure as a non-binding estimate (Richtpreis), never as an offer; the binding price follows after on-site measurement.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "area_m2": "<area_m2>"
    },
    "name": "calculate_spanndecken_price"
  }
}

Input Schema

Name	Required	Description	Default
`lamps`	No	Number of lamps / ceiling outlets (Leuchten). Optional; standard value 0.
`area_m2`	Yes	Ceiling area in square metres (Deckenfläche in m²), e.g. 20 or 35.5. Required — the only parameter the user must provide.
`corners`	No	Number of room corners (Raumecken); 4 are included in the price. Optional; standard value 4.
`category`	No	Surface category (Oberflächen-Kategorie): A = Lack / Matt / Satin with colour choice, B = Metallic / Exclusive / Galaxy, C = Fotodruck (photo print). Optional; standard value A when omitted.	A
`spotlights`	No	Number of recessed spotlights (Einbaustrahler). Optional; standard value 0.
`volume_discount`	No	Apply the online calculator's volume-discount option (Mengenrabatt), e.g. for several rooms. Optional; standard value false.

Output Schema

Name	Required	Description
`input`	Yes	Parameters actually used (after validation and server-side defaults).
`quote`	Yes
`notice`	Yes
`status`	Yes	Always "ok" for a successful calculation.
`provider`	Yes	Identity of the provider; show the website with every result.
`calculated_at`	Yes	ISO 8601 timestamp of the calculation.
`pricing_version`	Yes	Version date of the pricing basis (YYYY-MM-DD).
`defaults_applied`	Yes	Names of the parameters the server filled in with standard values because the request did not provide them; empty when every value was given explicitly. Tell the user which values were assumed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses important behavior: omitted parameters are server-filled with defaults, any user-provided value overrides those defaults, and the result repeats the parameters used and lists assumed defaults in defaults_applied. It also explains the non-binding nature of the estimate and that binding pricing follows an on-site measurement.

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?

The description is front-loaded with the core purpose and then moves through required input, defaults, categories, and presentation guidance. It is longer than average but the length is largely justified by the defaulting behavior and non-binding pricing caveat; some category/default detail repeats information also present in the schema.

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 six-parameter pricing tool with an output schema, the description is complete: it covers invocation with only area_m2, server-side defaulting, override behavior, what the result communicates, and how the agent should present the estimate. Nothing critical for correct invocation is missing.

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?

Schema description coverage is 100%, so the schema already documents each parameter, its default, and the enum values. The description still adds meaningful semantics by explaining that only area_m2 is mandatory, that the server applies standard values for omitted parameters, and that user-stated values override them.

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 states a specific verb and resource: it calculates a non-binding EUR price estimate for a stretch ceiling from Spanndecken ROTH using the online calculator's formula. This is clearly distinguishable from generic pricing tools, and the brand/domain scope is explicit.

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 clearly explains that only area_m2 is required and that all other parameters may be omitted and are filled with standard values. It also tells the agent how to frame the result: present it as a non-binding estimate, never as an offer. There are no sibling tools to route between, but the usage context is strong.

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

All Spanndecken ROTH Preisrechner tools Inspect

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

Need Help?