rechtsklar24

Grundpreis nach § 5 PAngV berechnen

calculate_grundpreis

Read-onlyIdempotent

Use when someone wants the base price (Grundpreis) for a product: "Grundpreis berechnen", "Preis pro Kilo/Liter/Meter/Quadratmeter", "12,90 € für 750 g". Input: total price including VAT, quantity and unit (g, kg, ml, l, mm, cm, m, cm2, m2, m3, stk). Returns the Grundpreis per legal reference unit (1 kg, 1 l, 1 m, 1 m², 1 m³ under § 5 PAngV; 100 g or 100 ml only with loose_goods=true), rounded to two decimals exactly like the calculator on rechtsklar24.de. A per-piece price is computed but flagged as not a Grundpreis (§ 4 PAngV). Arithmetic on the user's numbers only; it does not judge whether a specific offer is lawful.

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": {
      "price": "<price>",
      "quantity": "<quantity>",
      "unit": "<unit>"
    },
    "name": "calculate_grundpreis"
  }
}

Input Schema

Name	Required	Description
`unit`	Yes	Einheit der Menge: g, kg (Gewicht); ml, l (Volumen); mm, cm, m (Länge); cm2, m2 (Fläche); m3 (Raummaß); stk = Stückzahl (kein Grundpreis).
`price`	Yes	Gesamtpreis in Euro inklusive Umsatzsteuer, z. B. 12.9.
`quantity`	Yes	Füllmenge oder Inhalt in der angegebenen Einheit, z. B. 750.
`loose_goods`	No	true nur bei loser, unverpackter Ware nach Gewicht oder Volumen: dann 100 g bzw. 100 ml als Bezugsgröße (§ 5 Absatz 2 PAngV). Standard false.

Output Schema

Name	Required	Description
`menge`	Yes
`preis`	Yes
`stand`	No
`fakten`	Yes
`status`	Yes	kein_grundpreis = Preis je Stück: § 4 PAngV kennt dafür keinen Grundpreis; der Wert wird trotzdem ausgerechnet.
`einheit`	Yes
`hinweis`	No
`info_url`	Yes
`rechnung`	Yes
`lose_ware`	Yes
`disclaimer`	Yes
`grundpreis`	Yes	Auf zwei Nachkommastellen gerundet.
`register_url`	Yes
`bezugsgroesse`	Yes
`grundpreis_text`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world behavior, and the description adds genuinely new context: two-decimal rounding matching a specific calculator, the per-piece result being flagged as not a Grundpreis, and the explicit limit to arithmetic on the user's own numbers. Return shape and pagination-style concerns are covered by the output schema.

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-loaded with the trigger condition and example utterances, followed by input and output expectations in a compact block. It is slightly dense with legal citations (PAngV § 4, § 5) that could be trimmed, but every sentence contributes.

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 simple four-parameter arithmetic tool with an output schema and full annotation coverage, the description supplies input meaning, output unit basis, rounding behavior and explicit scope limits. Nothing an agent needs to call it correctly is missing.

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 100% and the enum values, price/quantity semantics and the loose_goods rule are all documented in the schema itself. The description restates the unit list and the loose-goods reference-unit rule without adding format or edge-case detail beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('compute the Grundpreis') and pins the legal anchor (§ 5 PAngV). It is unmistakably distinct from the siblings (fine ceilings, obligation dates, study facts), which are unrelated lookups, so an agent can route correctly from the description alone.

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?

Opens with an explicit 'Use when...' clause plus realistic trigger phrasings ('Grundpreis berechnen', 'Preis pro Kilo/Liter'). It also draws a scope boundary ('does not judge whether a specific offer is lawful'), but never names alternatives or when-not to use it, so it stops short of full explicit routing.

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

All rechtsklar24 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?