Preise für Steinreinigung, Fugen und Heckenschnitt in Schleswig-Holstein und Hamburg.
Scored across 3 tools
The three tools target clearly different tasks: hedge trimming pricing, joint material comparison, and stone/paving cleaning pricing. The two *_preis_berechnen tools share a suffix but operate on entirely different service domains, so confusion risk is low, though the shared verb phrasing could momentarily blur them.
All names are snake_case German with a domain prefix (heckenschnitt_, steinreinigung_) followed by an action phrase, giving a predictable structure. The verb placement varies slightly (preis_berechnen vs fugen_vergleichen) but the overall pattern is readable and consistent.
Only three tools, which is borderline thin even for a focused price calculator. The scope is coherent, but the surface feels minimal, and there is little room for the agent to navigate beyond the two pricing flows plus one comparison helper.
Pricing coverage exists for two service lines plus a material comparison, which fits the 'Preisrechner' purpose. However, there is no path to convert an estimate into an actual request/booking, and hole/fugen comparison only exists for stone cleaning, leaving hedge trimming with no analogous configuration aid.
Schätzt den Preis von Pflasterlux für einen Heckenschnitt im Umkreis von 50 km um Fleckeby (Schleswig, Eckernförde, Kiel): Länge, heutige Höhe, welche Flächen geschnitten werden und wie viel oben abkommt. Gibt die Rechnung Zeile für Zeile in Euro brutto zurück, mit Aufräumen, Abtransport, Entsorgung und Anfahrt. Sendet keine Anfrage.
| Name | Required | Description | Default |
|---|---|---|---|
| art | No | Heckenart: thuja (Thuja oder Zypresse, schuppige, flache Zweige), kirschlorbeer (Kirschlorbeer, große, glänzende Blätter), liguster (Liguster, kleine, ovale Blätter), buche (Hainbuche oder Buche, Laub, oft bis in den Winter), eibe (Eibe, weiche, dunkle Nadeln), buchsbaum (Buchsbaum, kleine, feste Blätter), andere (Andere Hecke, etwa Glanzmispel), unbekannt (Weiß ich nicht, erkennen wir am Foto). Ändert den Preis nicht, sagt aber, wie weit gekürzt werden kann. | |
| hoehe | Yes | Höhe, die die Hecke heute hat: bis-100 (bis 1 m, hüfthoch), bis-150 (1–1,5 m, brusthoch), bis-200 (1,5–2 m, kopfhoch), bis-250 (2–2,5 m, über Kopf), bis-300 (2,5–3 m, mit Podest), bis-350 (3–3,5 m, mit Gerüst), ueber-350 (über 3,5 m, mit Bühne). | |
| knick | No | Steht die Hecke auf einem Erdwall oder direkt an einem Feld (Knick)? Knicks sind in Schleswig-Holstein geschützt. | |
| kuerzen | No | Wie viel oben abkommt: zuwachs (Nur der Zuwachs, Formschnitt, Höhe bleibt), bis-50 (Bis 50 cm, etwas niedriger), bis-100 (50 cm–1 m, deutlich niedriger), ueber-100 (Über 1 m, stark gekürzt). Ohne Angabe: zuwachs. Kürzen ist nur vom 1. Oktober bis Ende Februar erlaubt. | |
| flaechen | No | Was geschnitten wird: beide-oben (Beide Seiten und oben, der Standard), eine-oben (Eine Seite und oben, an der Grundstücksgrenze), beide (Beide Seiten, ohne Oberseite), eine (Nur eine Seite, ohne Oberseite). Ohne Angabe: beide-oben. | |
| laenge_m | Yes | Länge der Hecke in Metern, 1 bis 300. | |
| mit_reinigung | No | Gemeinsamer Termin mit einer Steinreinigung von Pflasterlux; der Heckenschnitt wird dann günstiger. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by stating what the output contains (a line-by-line calculation in gross Euro including cleanup, transport, disposal and travel) and, crucially, that no request is dispatched — reinforcing the read-only profile with real meaning for the agent. It adds no cost-variance or accuracy caveats, keeping it at 4.
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?
Three short sentences: what it estimates and where, which inputs matter, what comes back, and the side-effect guarantee. The input list is a compact preview rather than redundant restatement, and the key facts are front-loaded.
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?
No output schema exists, and the description compensates by describing the return value's structure and components. With full schema coverage on all seven parameters, the only remaining gap is minor — it doesn't explain the seasonal/pruning legal constraint or that hedge type does not affect price, both of which live in the schema.
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 enum parameters carry rich per-value explanations, so the schema already does the heavy lifting. The description names only four of the seven inputs (Länge, Höhe, Flächen, Kürzen) and adds no format or unit detail beyond what the schema provides — baseline 3.
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 ("Schätzt den Preis") plus the exact resource (Heckenschnitt), the provider (Pflasterlux) and the geographic scope (50 km um Fleckeby). The resource is plainly distinct from the steinreinigung siblings, so an agent can route without opening either schema.
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?
Gives clear context for use: an estimate, limited to a 50 km radius, requiring length and height. It never names an alternative tool or an explicit when-not-to-use case, so 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet die Fugenmaterialien von Pflasterlux für einen Belag, eine Fugenbreite und eine Nutzung auf: Preis je m² zusätzlich zur Reinigung, wann welches Material passt, was nicht geht und die Empfehlung.
| Name | Required | Description | Default |
|---|---|---|---|
| belag | No | Belag der Fläche: betonpflaster (Betonpflaster, Verbund- oder Rechteck, etwa 20 × 10 cm), grossbeton (Große Betonsteine, Quadrate, Großformate ab 20 × 20 cm), betonplatten (Beton- oder Waschbetonplatten, ab etwa 40 × 40 cm), klinker (Klinker, gebrannter Ton, etwa 20 × 10 cm), kleinpflaster (Granit-Kleinpflaster, Granitwürfel, etwa 10 cm), kopfstein (Kopfsteinpflaster, Granit ab 13 cm, auch Feldsteine), granitplatten (Granitplatten, auch Basalt und Gneis), sandsteinplatten (Sandsteinplatten, auch Kalkstein und Travertin), polygonal (Polygonalplatten, Bruchplatten, meist im Mörtel), keramik (Keramikplatten, Feinsteinzeug, „Klinkerplatten“), unbekannt (wir rechnen wie bei Betonpflaster). | |
| nutzung | No | Belastung der Fläche: fuss (Ohne Transporter und LKW, Fußgänger und PKW bis 3,5 t), lkw (Transporter, LKW, über 3,5 t). Ohne Angabe: fuss. | |
| fugenbreite | No | Breite der Fugen: bis-5 (bis 5 mm), bis-8 (bis 8 mm), bis-12 (bis 12 mm), bis-20 (bis 20 mm), ueber-20 (über 20 mm), unbekannt (wir rechnen mit der typischen Breite des Belags). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds real behavioral value by enumerating what comes back — prices per m², suitability per material, what does not work, and a recommendation — which is important since no output schema exists.
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 that leads with the verb and resource and then enumerates the return contents; almost every clause earns its place. It is somewhat long and colon-chained, but nothing is redundant.
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 and fully optional parameters that all have documented defaults, the description carries the load of telling the agent what the tool returns — and it does so concretely. A brief note on when to prefer it over the sibling price calculator is the only real gap.
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 all three parameters are fully enumerated with detailed value glosses, including defaults ("Ohne Angabe: fuss", "unbekannt (wir rechnen wie bei Betonpflaster)"). The description restates the three input dimensions but adds no semantics beyond the schema, so the baseline 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 concrete verb ("Listet ... auf") and a concrete resource ("Fugenmaterialien von Pflasterlux") scoped by three inputs (Belag, Fugenbreite, Nutzung), and even sketches the output (Preis je m², wann welches Material passt, Empfehlung). It does not explicitly distinguish itself from the sibling steinreinigung_preis_berechnen, so the agent must infer the comparison-vs-calculation split from the name alone.
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 implies the usage context (choosing a joint material, with the cleaning price as a reference), and the phrase "Preis je m² zusätzlich zur Reinigung" hints that this is not the plain cleaning price tool. But there is no explicit "use this when / use X instead" statement, and the sibling price calculators are never mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Berechnet den Preis von Pflasterlux für die Reinigung einer Pflaster- oder Terrassenfläche in Schleswig-Holstein und Hamburg, auf Wunsch mit neuer Fuge, Imprägnierung oder Farbbeschichtung und Unkrautbekämpfung, auf Wunsch mit dem Preis je Besuch für den Pflegeplan danach. Gibt die Rechnung Zeile für Zeile in Euro brutto zurück, mit einem Link auf dieselbe Auswahl im Preisrechner. Sendet keine Anfrage.
| Name | Required | Description | Default |
|---|---|---|---|
| fuge | No | Neue Fuge: keine (nur reinigen), empfehlung (unsere Empfehlung für diese Fläche), quarzsand (Quarzsand, Lose Fuge), natursand (Natursand, Halbfeste Fuge), polymersand (Polymersand, Feste Fuge, elastisch), moertel-1k (1K-Mörtel, Feste Fuge), moertel-2k (2K-Mörtel, Feste Fuge, breite Fugen), splitt (Basaltsplitt, Lose Fuge, grobes Korn). Ohne Angabe: keine. | |
| belag | No | Belag der Fläche: betonpflaster (Betonpflaster, Verbund- oder Rechteck, etwa 20 × 10 cm), grossbeton (Große Betonsteine, Quadrate, Großformate ab 20 × 20 cm), betonplatten (Beton- oder Waschbetonplatten, ab etwa 40 × 40 cm), klinker (Klinker, gebrannter Ton, etwa 20 × 10 cm), kleinpflaster (Granit-Kleinpflaster, Granitwürfel, etwa 10 cm), kopfstein (Kopfsteinpflaster, Granit ab 13 cm, auch Feldsteine), granitplatten (Granitplatten, auch Basalt und Gneis), sandsteinplatten (Sandsteinplatten, auch Kalkstein und Travertin), polygonal (Polygonalplatten, Bruchplatten, meist im Mörtel), keramik (Keramikplatten, Feinsteinzeug, „Klinkerplatten“), unbekannt (wir rechnen wie bei Betonpflaster). | |
| schutz | No | Schutz der Oberfläche: keiner, impraegnierung (Steinoptik bleibt), beschichtung (neue Farbe, nur auf Betonstein). Ohne Angabe: keiner. | |
| farbton | No | Farbton der Beschichtung: anthrazit (Anthrazit), schwarz (Schwarz), steingrau (Steingrau), naturrot (Naturrot). Nur mit schutz = beschichtung. | |
| nutzung | No | Belastung der Fläche: fuss (Ohne Transporter und LKW, Fußgänger und PKW bis 3,5 t), lkw (Transporter, LKW, über 3,5 t). Ohne Angabe: fuss. | |
| flaeche_m2 | Yes | Größe der Fläche in Quadratmetern, eine grobe Schätzung genügt. Über 500 m² gibt es ein eigenes Angebot statt eines Preises. | |
| fugenbreite | No | Breite der Fugen: bis-5 (bis 5 mm), bis-8 (bis 8 mm), bis-12 (bis 12 mm), bis-20 (bis 20 mm), ueber-20 (über 20 mm), unbekannt (wir rechnen mit der typischen Breite des Belags). | |
| pflegeplan_danach | No | Nach der Reinigung in den Pflegeplan: Wir kommen ein- bis dreimal im Jahr wieder, gegen Grünbelag und mit thermischer Unkrautbekämpfung. Nur im Umkreis von 40 km um Fleckeby. Die Reinigung ist dann die Grundreinigung, mit der jeder Pflegeplan beginnt; der Preis je Besuch steht neben der Rechnung, nicht darin. | |
| unkraut_heisswasser | No | Zusätzliche Unkrautbekämpfung mit Heißwasser im selben Termin, für Unkraut mit tiefen Wurzeln. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real behavioral context beyond them: the return is a line-by-line gross-EUR invoice with a deep link back into the price calculator, and crucially that no request/booking is transmitted; the region limit is also disclosed inline.
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?
The core capability is front-loaded in the first sentence, and the return behavior plus the 'no request sent' caveat follow logically. Mild redundancy from the repeated 'auf Wunsch' construction, but no sentence is filler.
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 nine parameters, six enums and no output schema, the description correctly fills the return-value gap by describing the line-item EUR invoice and the calculator link, and it states the geographic and >500 m² boundaries. It stops short of clarifying the Pflegeplan radius/dependency at the description level (that sits in the schema), which is a minor omission for a tool of this complexity.
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 each of the nine parameters is documented at the field level, so the schema does the heavy lifting. The description only restates the option groups (Fuge, Imprägnierung, Farbbeschichtung, Unkrautbekämpfung, Pflegeplan-Preis je Besuch) without adding format, dependency or default semantics beyond what the schema already provides.
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 and resource ('Berechnet den Preis ... für die Reinigung einer Pflaster- oder Terrassenfläche') and scopes it geographically to Schleswig-Holstein and Hamburg, including the optional add-ons. It is clearly distinguishable from heckenschnitt_preis_berechnen by resource, but it never explicitly contrasts itself with the sibling steinreinigung_fugen_vergleichen, leaving that differentiation 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?
Usage is implied rather than stated: the agent can infer this is the price-calculation tool, and 'Sendet keine Anfrage' usefully signals that calling it is non-committal. However, there is no explicit when-to-use/when-not guidance and no reference to the sibling fugen_vergleichen tool, which an agent comparing the two would want.
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.
heckenschnitt_preis_berechnensteinreinigung_fugen_vergleichensteinreinigung_preis_berechnenContainerdienste in Deutschland finden, Preise vergleichen und kostenlos Angebote anfordern.
Real-world tasks in Hamburg: quote, check service area, submit an enquiry for human review.
Deutscher Preisvergleich für Solaranlagen & Balkonkraftwerke – Bestpreis-Suche (read-only).
Auftraege, Rechnungen, Material und Zeiten eines Handwerksbetriebs abfragen und pflegen.
Add one secure layer between your agents and this server.
