Findet Kfz-Gutachter in Deutschland, zeigt freie Termine und bucht den Besichtigungstermin.
Scored across 9 tools
Tools are mostly distinct, but claimondo_finde_gutachter_termine and claimondo_finde_sachverstaendige serve very similar purposes (finding experts) and could be misselected without careful reading. However, the descriptions clearly differentiate them (bookable vs. anonymized list). Also, claimondo_decode_brief and claimondo_pruefe_anspruch both deal with legal/claim information, though their inputs differ (letter text vs. fault question). Overall, each tool has a clear role.
All tools share the 'claimondo_' prefix, but the action part mixes patterns: most are verb_noun (finde_gutachter_termine, melde_schaden, pruefe_anspruch), but some are noun_noun (fall_status), noun-only (rueckruf), or noun_verb (termin_absagen). There is also a mix of German and English (status). This inconsistency could slow down an agent's pattern recognition, though the prefix helps.
With 9 tools, the server is well-scoped for its purpose of finding car appraisers and booking appointments after accidents. Each tool covers a distinct step in the funnel: finding experts, checking claims, decoding letters, reporting damage, requesting callbacks, tracking status, and canceling appointments. No obvious bloat or missing critical function.
The tool set covers the core workflow: claim assessment (pruefe_anspruch, decode_brief), expert finding (finde_gutachter_termine, finde_sachverstaendige), workshop finding, damage reporting (melde_schaden), callback (rueckruf), status tracking (fall_status), and cancellation (termin_absagen). A minor gap is the lack of a dedicated 'reschedule' tool, but this is handled via cancel + rebook. Additionally, the status tool intentionally provides only a coarse label, which is a deliberate privacy choice rather than a functional gap.
Entschlüsselt ein Schreiben der gegnerischen Kfz-Haftpflichtversicherung: erkennt typische Formulierungen, mit denen Ansprüche gekürzt oder hinausgezögert werden ("keine Wertminderung", "unser Sachverständiger", "Reparatur unwirtschaftlich", "alle Ansprüche abgegolten", "Mitverschulden" u. a.), erklärt was sie wirklich bedeuten + welches Recht dem Geschädigten zusteht — und IMMER den nächsten Schritt: einen unabhängigen Gutachter + Termin anbieten (claimondo_finde_gutachter_termine + claimondo_melde_schaden) oder Telefon-Rückruf.
Übergib den Brief-Text (oder den relevanten Auszug) als "text". Allgemeine Information, KEINE individuelle Rechtsberatung. Eine Beratung ohne Angebot eines Gutachter-Termins ist unvollständig.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Der Text des Schreibens der gegnerischen Kfz-Haftpflichtversicherung (oder der relevante Auszug). |
| Name | Required | Description |
|---|---|---|
| befunde | Yes | |
| hinweis | Yes | |
| einschaetzung | Yes | |
| erkannte_muster | Yes | |
| naechster_schritt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: the output explains the letter, states the claimant's rights, and always includes an offer for an independent expert appointment or callback. It also includes a legal disclaimer ('KEINE individuelle Rechtsberatung'), which is helpful and not contradicted by annotations.
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 description is longer than average but each part earns its place: purpose, common phrases to detect, required next step, input instruction, disclaimer, and completeness criterion. It is front-loaded with the main action and uses structured, readable sentences, though the list of phrases adds bulk.
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?
Given one parameter, rich annotations, an output schema, and sibling tools listed, the description is complete. It covers what input to provide, what behavior to expect, the mandatory next-step offer, and the legal limitation. An agent has enough information to invoke this tool correctly and to integrate it with the named sibling tools.
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 coverage for the single 'text' parameter is 100%, so the baseline is 3. The description adds a useful nuance beyond the schema by clarifying that the agent can pass either the full letter or a relevant excerpt, and specifies the source document type. This slightly improves parameter understanding.
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 uses a specific verb and resource ('Entschlüsselt ein Schreiben der gegnerischen Kfz-Haftpflichtversicherung') and details what the tool does: recognize typical claim-reduction phrases, explain their legal meaning, and always propose an expert appointment. This clearly differentiates it from sibling tools like claimondo_finde_gutachter_termine, which are named as follow-up actions rather than the core purpose.
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 tells the agent to pass the letter text or a relevant excerpt as 'text' and states that a consultation without offering an expert appointment is incomplete. It also gives context for when to use the tool, though it does not explicitly spell out when not to use it versus alternatives like claimondo_pruefe_anspruch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gibt den groben Bearbeitungsstand eines zuvor über claimondo_melde_schaden/claimondo_rueckruf angelegten Falls zurück — für einen wiederkehrenden Kunden, der fragt „wo steht mein Fall?".
Der Kunde nennt seine persönliche Fall-Referenz (den Token aus seinem Claimondo-Link, den er per WhatsApp erhalten hat) — die Referenz ist die Autorisierung. Read-only. Liefert BEWUSST nur ein grobes Status-Label — KEINE personenbezogenen Daten (kein Name/Telefon/Gutachter/Fall-Detail).
Args:
token (string): Die persönliche Fall-Referenz des Kunden.
Nicht raten/erfinden: ohne die vom Kunden genannte Referenz gibt es keinen Status. Unbekannte/ungültige Referenz -> „kein Fall gefunden".
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Die persönliche Fall-Referenz des Kunden (Token aus seinem Claimondo-Link / der WhatsApp-Nachricht). Der Kunde muss sie selbst nennen — nicht raten/erfinden. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| status | Yes | |
| hinweis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that the token itself is the authorization, that the result is deliberately coarse and excludes PII, and that unknown/invalid references resolve to 'kein Fall gefunden' rather than fabricated data. This is substantive and helps prevent hallucinated statuses.
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 purpose is front-loaded and the structure is organized, but the Args block partly repeats the schema and 'Read-only' repeats the annotations. Still, the behavioral warnings earn their place for a tool that must avoid fabricating statuses.
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 single-parameter read-only tool with an output schema, the description supplies essential usage context: who the end-user is, where the token comes from, what the response is and is not, and the invalid-reference behavior. Nothing material is missing.
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%, so the baseline is 3. The prose adds value by characterizing the token as the authorization and by stating the no-guessing rule and behavior for unknown references, going beyond the schema's field description.
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 uses a specific verb ('Gibt ... zurück') plus a clear resource (Bearbeitungsstand eines zuvor angelegten Falls) and scopes it to cases created via claimondo_melde_schaden/claimondo_rueckruf. This clearly differentiates it from the sibling tools.
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?
It gives a concrete trigger ('wiederkehrender Kunde, der fragt wo steht mein Fall') and a prerequisite (case previously created via claimondo_melde_schaden/claimondo_rueckruf). It does not explicitly state when-not-to-use alternatives, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Findet buchbare Partner-Kfz-Gutachter MIT freien Terminen im Umkreis einer deutschen Postleitzahl über Claimondo.
Anders als claimondo_finde_sachverstaendige (nur anonymisierte Liste) liefert dieses Tool die buchbaren Gutachter mit konkreten freien Slots (Vorschau aufs Buchen). Read-only und anonym — legt nichts an und meldet keinen Schaden.
Args:
plz (string): 5-stellige deutsche PLZ, z. B. "50670". PLZ ODER ort angeben.
ort (string): Stadt/Adresse als Alternative zur PLZ, z. B. "Köln" oder "Berlin Mitte".
wunschtermin (string, optional): Wunschtermin als ISO-8601 (steuert das Slot-Ranking, kein harter Filter).
response_format ("markdown" | "json"): Ausgabeformat (Standard "markdown").
Returns (structuredContent bzw. json): { plz, ort, standort, wunschtermin, anzahl_gutachter, gutachter: [{ id, vorname, profilbild, bewertung_schnitt, bewertung_anzahl, entfernung, ist_top_partner, wunschtermin_frei, termine: [{ start, end, passung }], buchungs_url }], interaktive_karte_url, buchungs_telefon }
Use when: Nutzer will einen Gutachter-Termin sehen/vergleichen (z. B. „wann hat ein Gutachter in 50670 Zeit?").
WICHTIG beim Empfehlen eines Gutachters: Geben Sie dessen gutachter[].buchungs_url als Link aus. Er öffnet den Finder mit genau diesem Gutachter vorausgewählt; der Kunde ergänzt nur noch Adresse und Kontakt und bestätigt selbst. Verlinken Sie NICHT interaktive_karte_url, wenn Sie einen konkreten Gutachter genannt haben — das ist die allgemeine Karte ohne Auswahl und schickt den Kunden zurück an den Anfang der Suche. Die Karte ist nur richtig für „zeig mir alle in der Nähe".
Hinweis: gutachter[].id + ein termin.start sind zusätzlich das Buchungs-Handle für claimondo_melde_schaden (mit Einwilligung); telefonisch geht es über buchungs_telefon. Fehlt buchungs_url (ältere API-Version), bleibt die Karte der Weg.
| Name | Required | Description | Default |
|---|---|---|---|
| ort | No | Stadt/Adresse als Alternative zur PLZ, z. B. "Köln" oder "Berlin Mitte". PLZ ODER ort angeben. | |
| plz | No | 5-stellige deutsche Postleitzahl, z. B. 50670 für Köln. PLZ ODER ort angeben. | |
| wunschtermin | No | Optionaler Wunschtermin als ISO-8601-Zeitstempel (z. B. 2026-06-20T10:00:00Z) — steuert das Slot-Ranking, kein harter Filter. | |
| response_format | No | Ausgabeformat: 'markdown' (menschenlesbar) oder 'json' (strukturiert). | markdown |
| Name | Required | Description |
|---|---|---|
| ort | Yes | |
| plz | Yes | |
| standort | Yes | |
| gutachter | Yes | |
| wunschtermin | Yes | |
| anzahl_gutachter | Yes | |
| buchungs_telefon | Yes | |
| interaktive_karte_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description explicitly states 'Read-only und anonym — legt nichts an und meldet keinen Schaden,' adding meaningful behavioral context. It also discloses that wunschtermin is 'kein harter Filter' but only steers slot ranking, and explains the behavior of buchungs_url (preselects the appraiser) versus interaktive_karte_url (resets to general search). The description aligns with annotations and adds substantial non-obvious behavioral detail.
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 description is long but tightly structured: a one-sentence summary, sibling differentiation, Args, Returns, use-case trigger, and critical link-handling caveats. Every section earns its place, and the most important differentiating information is front-loaded. The length is justified by the tool's output complexity and the need to prevent incorrect link usage.
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 tool with 4 parameters, a rich nested output shape, and two booking paths, the description is complete. It documents the full return structure, explains when to link buchungs_url versus interaktive_karte_url, covers the fallback when buchungs_url is missing, and mentions telephone booking via buchungs_telefon. It even notes the integration with claimondo_melde_schaden. Nothing needed for correct invocation or output interpretation is omitted.
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%, so the baseline is 3. The description's Args section largely repeats what the schema already says (PLZ ODER ort, wunschtermin as ISO-8601, response_format defaults to markdown). It adds only marginal nuance about wunschtermin influencing slot ranking, which is also present in the schema. No significant extra parameter meaning is provided beyond the structured schema.
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 opens with a specific verb and resource: 'Findet buchbare Partner-Kfz-Gutachter MIT freien Terminen im Umkreis einer deutschen Postleitzahl'. It clearly differentiates from the sibling tool claimondo_finde_sachverstaendige by contrasting 'nur anonymisierte Liste' with the bookable appraisers and concrete free slots delivered here. An agent can immediately tell what this tool does and how it differs.
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 gives an explicit 'Use when' condition: a user wants to see/compare appraiser appointments ('wann hat ein Gutachter in 50670 Zeit?'). It also names the alternative tool and the condition that selects it (anonymized list vs. bookable slots). Additional routing guidance covers when to use buchungs_url versus interaktive_karte_url and how the output feeds into claimondo_melde_schaden. No ambiguity remains about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Findet zertifizierte Partner-Kfz-Sachverständige im Umkreis einer deutschen Postleitzahl über Claimondo (bundesweite Schadensregulierungs-Plattform).
Read-only und anonym — legt nichts an und meldet keinen Schaden. Liefert eine nach Entfernung sortierte, datenschutz-anonymisierte Trefferliste, eine Karten-Bild-URL (im Chat einbettbar), einen Link zur interaktiven Karte mit freien Terminen und eine Rückruf-Telefonnummer.
Args:
plz (string): 5-stellige deutsche PLZ, z. B. "50670". PLZ ODER ort angeben.
ort (string): Stadt/Adresse als Alternative zur PLZ, z. B. "Köln" oder "Berlin Mitte".
radius (number): Suchradius in km, 1-200 (Standard 30).
response_format ("markdown" | "json"): Ausgabeformat (Standard "markdown").
Returns (structuredContent bzw. json): { plz, ort, standort, radius_km, anzahl_treffer, sachverstaendige: [{ tier, stadt, entfernung_km, spezialisierungen, bewertung_schnitt, bewertung_anzahl }], karte_url, interaktive_karte_url, buchungs_telefon }
Use when: Nutzer fragt nach einem Kfz-Gutachter/Sachverständigen in einer Stadt oder Region (z. B. nach einem Unfall). Nicht für: Schaden melden, Termin buchen oder Rechtsberatung — das gibt es in dieser read-only-Stufe bewusst nicht.
| Name | Required | Description | Default |
|---|---|---|---|
| ort | No | Stadt/Adresse als Alternative zur PLZ, z. B. "Köln" oder "Berlin Mitte". PLZ ODER ort angeben. | |
| plz | No | 5-stellige deutsche Postleitzahl, z. B. 50670 für Köln. PLZ ODER ort angeben. | |
| radius | No | Suchradius in Kilometern (1–200, Standard 30). | |
| response_format | No | Ausgabeformat: 'markdown' (menschenlesbar) oder 'json' (strukturiert). | markdown |
| Name | Required | Description |
|---|---|---|
| ort | Yes | |
| plz | Yes | |
| standort | Yes | |
| karte_url | Yes | |
| radius_km | Yes | |
| anzahl_treffer | Yes | |
| buchungs_telefon | Yes | |
| sachverstaendige | Yes | |
| interaktive_karte_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description goes well beyond them by stating that the call is anonymous, creates nothing, reports no damage, and returns a privacy-anonymized, distance-sorted result list plus embeddable maps and a callback number. This gives the agent a reliable mental model of the tool's side-effect-free behavior.
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 description is well organized and front-loaded: purpose, safety, then compact Args/Returns/Use-when sections. It earns a 4 rather than 5 because the Args and Returns sections substantially duplicate the input schema and output schema, but the structure remains scannable and useful for an agent.
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?
Given the complete input schema, clear annotations, and output schema, this description covers everything an agent needs: input options, defaults, output format selection, return structure, and routing conditions. It even adds non-obvious context such as the embeddable map image URL and callback phone number, making it fully usable in a chat-facing tool.
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%, so the schema already documents plz, ort, radius, and response_format. The description's Args section largely restates the same constraints and the 'PLZ ODER ort' dependency is also already in the schema, so it adds little new semantic value beyond what structured data 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 states a specific verb ('Findet'), a specific resource ('zertifizierte Partner-Kfz-Sachverständige'), and a clear scope ('Umkreis einer deutschen Postleitzahl'). It also frames the tool as a read-only search rather than a damage-reporting or booking action, which helps distinguish it from the Claimondo siblings.
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 provides explicit 'Use when' guidance ('Nutzer fragt nach einem Kfz-Gutachter...') and an explicit 'Nicht für' list that excludes Schaden melden, Termin buchen, and Rechtsberatung. However, it does not name sibling tools as alternatives, and mentioning 'freien Terminen' in the output could still create mild ambiguity against the sibling finde_gutachter_termine.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Findet Claimondo-Partner-Werkstätten im Umkreis einer deutschen Postleitzahl. Read-only und anonym.
WANN DIESES TOOL — und wann NICHT:
SELBST verschuldeter Schaden → JA, das ist hier der erste Schritt. Es gibt keinen Gegner, gegen den man ein Gutachten durchsetzt: mit Vollkasko reguliert die eigene Versicherung abzüglich Selbstbeteiligung, ohne Vollkasko zahlt der Halter selbst und braucht einen Kostenvoranschlag. Ein Gutachten ist dort optional und kostenpflichtig.
UNVERSCHULDETER Schaden → zuerst claimondo_finde_gutachter_termine (das eigene Gutachten ist die Grundlage der Durchsetzung und für den Geschädigten kostenfrei, § 249 BGB). Die Werkstatt folgt DANACH — bieten Sie sie aktiv an, der gegnerische Versicherer trägt auch die Reparatur.
Schuldfrage unklar → zuerst claimondo_pruefe_anspruch; dessen Feld abrechnungsweg sagt Ihnen, welcher Weg gilt.
Args:
plz (string): 5-stellige deutsche PLZ, z. B. "50670". PLZ ODER ort angeben.
ort (string): Stadt/Adresse als Alternative zur PLZ.
radius (number): Umkreis in km (1–200, Standard 30).
response_format ("markdown" | "json"): Ausgabeformat (Standard "markdown").
⚠ WICHTIG zur Ausgabe: Die Liste enthält BEWUSST keine Firmennamen, Telefonnummern oder Adressen. Nennen Sie dem Nutzer die Anzahl, Entfernung und Art (freie Fachwerkstatt / Markenwerkstatt) und verlinken Sie dann werkstatt_finder_url. Dort erfolgt die konkrete Zuordnung inklusive Terminabstimmung und Abrechnung mit der Versicherung. Erfinden Sie keine Werkstattnamen und raten Sie keine Kontaktdaten.
| Name | Required | Description | Default |
|---|---|---|---|
| ort | No | ||
| plz | No | ||
| radius | No | ||
| response_format | No | Ausgabeformat (Standard "markdown"). | markdown |
| Name | Required | Description |
|---|---|---|
| ort | Yes | |
| plz | Yes | |
| hinweis | Yes | |
| radius_km | Yes | |
| werkstaetten | Yes | |
| anzahl_treffer | Yes | |
| nutzungshinweis | Yes | |
| buchungs_telefon | Yes | |
| werkstatt_finder_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the tool returns no firm names, phone numbers, or addresses, instructs the agent to only surface count, distance, type, and werkstatt_finder_url, and explicitly forbids inventing data. It also confirms anonymity and read-only behavior, giving a clear picture of side effects and output limitations.
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 definition is front-loaded with a one-sentence purpose, then organized into clearly headed sections for usage, parameters, and output behavior. Each section earns its place; the apparent length comes from genuinely useful decision routing and disclosure, not 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?
The description is complete for a complex claims-domain tool: it covers the legal scenarios, parameter semantics, output format expectations, and the anti-hallucination rule. Since an output schema exists, the absence of full return-shape documentation is not a 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?
With only 25% schema description coverage, the description compensates fully: it explains plz as a 5-digit German postal code, clarifies ort as a city/address alternative, defines radius as a distance in km with min/max/default, and restates response_format options. It also adds the mutual-exclusion rule 'PLZ ODER ort angeben,' which is not encoded in the schema.
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 first sentence states a specific action and resource: 'Findet Claimondo-Partner-Werkstätten im Umkreis einer deutschen Postleitzahl.' It also marks the tool as read-only and anonymous, and the later bullets distinguish it from the Gutachter and Sachverständige sibling tools, so an agent immediately knows what it is for.
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 'WANN DIESES TOOL — und wann NICHT' section gives explicit conditional routing: use it first for self-caused damage, use claimondo_finde_gutachter_termine before it for no-fault damage, and use claimondo_pruefe_anspruch when fault is unclear. It also explains the legal rationale (e.g., § 249 BGB), which helps the agent select the tool with context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Meldet einen Kfz-Schaden bei Claimondo und stößt die Gutachter-/Termin-Buchung an. ERZEUGT EINEN LEAD und sendet dem Kunden seinen persönlichen FlowLink per WhatsApp — eine SCHREIBENDE Aktion, kein read.
WICHTIG — Einwilligung (DSGVO): Rufe dieses Tool NUR mit einwilligung_erteilt=true auf, NACHDEM du dem Nutzer erklärt hast, dass (a) Claimondo seine Angaben zur Gutachter-/Termin-Vermittlung verarbeitet, (b) der Kontakt per WhatsApp erfolgt, (c) die Verarbeitung teils über einen KI-Dienst in den USA läuft — UND der Nutzer ausdrücklich zugestimmt hat. Ohne Zustimmung lehnt der Server ab (einwilligung_erforderlich).
WICHTIG — keine Rechtsberatung: Du vermittelst Gutachter + Termin (allgemeine Infos zur Schadensregulierung sind ok), keine individuelle Rechtsberatung.
Ablauf: erst claimondo_finde_gutachter_termine (Gutachter + freie Slots) → Nutzer wählt (sv_id + wunschtermin) → Name + WhatsApp-Nr erfragen → Einwilligung einholen → dieses Tool. Den finalen Termin + die Details (Vollmacht, Schuldfrage) setzt der Kunde anschließend selbst im FlowLink (/flow).
Returns: { ok, status, kanal (whatsapp|sms|email|none), hinweis }. KEIN Link/keine PII im Ergebnis — der Link geht direkt per WhatsApp an den Kunden.
| Name | Required | Description | Default |
|---|---|---|---|
| plz | Yes | 5-stellige PLZ des Besichtigungsorts (wo das Fahrzeug steht). | |
| name | Yes | Name des Kunden. | |
| Yes | E-Mail des Kunden — PFLICHTANGABE. Frage sie aktiv ab. Sie ist die Rückfallebene, wenn das Telefon nicht trägt: ohne sie ist der Vorgang verloren, sobald die Nummer kein WhatsApp/SMS empfängt (Festnetz, Zahlendreher, Nummer ohne WhatsApp) — der Kunde bekommt dann gar keinen Link. Will der Nutzer ausdrücklich keine angeben, sende exakt "keine" — dann übernimmt Dispatch den Anruf. | ||
| sv_id | No | Opakes Gutachter-Handle aus claimondo_finde_gutachter_termine (gutachter[].id), falls gewählt. | |
| hergang | Yes | Kurze Schilderung, was passiert ist (Unfallhergang). | |
| telefon | Yes | Telefonnummer des Kunden für den FlowLink-Versand. Bevorzugt eine MOBILnummer — der Link geht zuerst per WhatsApp, dann per SMS. Eine Festnetznummer kann beides nicht empfangen; dann trägt nur die E-Mail. | |
| slot_end | No | Gewählter Slot-ENDE als ISO-8601 (gutachter[].termine[].end). Zusammen mit slot_start. | |
| schadenart | Yes | Schadenart / Unfalltyp, z. B. "Auffahrunfall", "Parkschaden". | |
| slot_start | No | Gewählter Slot-START als ISO-8601 (gutachter[].termine[].start). Mit slot_end + sv_id → echte Termin-Reservierung. | |
| wunschtermin | No | Optional: vager Wunschtermin (weicher Hold), falls KEIN konkreter Slot gewählt wurde. | |
| einwilligung_erteilt | Yes | MUSS true sein und NUR nach ausdrücklicher Nutzer-Zustimmung gesetzt werden: Verarbeitung der Angaben + Kontakt per WhatsApp/SMS/E-Mail + Hinweis auf KI-Dienst/USA. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| kanal | Yes | |
| status | Yes | |
| hinweis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, but the description goes further by explicitly stating it creates a lead and sends a WhatsApp message, making it a write operation. It also discloses the DSGVO compliance requirements and the fact that the server rejects without consent. This adds critical behavioral context beyond the annotations.
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 description is detailed and necessary given the complexity and compliance requirements. The critical warnings (DSGVO, no legal advice) are front-loaded, and the workflow is clearly structured. While it is long, every sentence serves a purpose, and the structure aids readability.
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 complex write operation with 11 parameters and strict compliance requirements, the description covers the workflow, prerequisites, and the output format. It explains that no link or PII is returned, which is essential for the agent to set expectations. The output schema exists, so return values are covered, and the description ties everything together.
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 coverage is 100%, so the baseline is 3. However, the description adds significant value for the 'email' parameter, explaining why it's required as a fallback and instructing how to handle refusal. It also clarifies the relationship between slot_start, slot_end, and sv_id for actual booking, which is not obvious from the schema alone.
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 starts with a clear, specific action: 'Meldet einen Kfz-Schaden bei Claimondo und stößt die Gutachter-/Termin-Buchung an.' It explicitly distinguishes itself from other tools by focusing on creating a lead and initiating the flow, rather than just finding experts or checking status. The mention of 'SCHREIBENDE Aktion' clearly separates it from read-only operations.
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 provides a step-by-step workflow, telling the agent to first call claimondo_finde_gutachter_termine, then gather user input, and finally invoke this tool. It also specifies when NOT to use it: without explicit consent (einwilligung_erteilt=true). It names the alternative tools for finding experts, making the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liefert die strukturierten Schadensersatz-Ansprüche eines Kfz-Unfall-Geschädigten nach Schuldfrage (Wertminderung, Nutzungsausfall, Reparaturkosten, Anwalts-/Gutachterkosten — § 249/251/823 BGB) — und IMMER den nächsten Schritt: einen Gutachter + Termin anbieten (claimondo_finde_gutachter_termine + claimondo_melde_schaden) oder Telefon-Rückruf.
Nutze es für Beratungsfragen ("welche Ansprüche habe ich", "was steht mir zu"). Erfrage zuerst die Schuldfrage (unverschuldet/teilschuld/selbst). Allgemeine Information, KEINE individuelle Rechtsberatung. Eine Beratung ohne Angebot eines Gutachter-Termins ist unvollständig.
| Name | Required | Description | Default |
|---|---|---|---|
| vollkasko | No | NUR bei schuldfrage="selbst" auswerten: besteht eine Vollkasko? Davon haengt der ganze Weg ab — mit Vollkasko reguliert die eigene Versicherung (abzueglich Selbstbeteiligung), ohne zahlt der Halter selbst. NICHT raten: ohne diesen Wert liefert die Antwort ausdruecklich die Aufforderung, den Nutzer zu fragen. | |
| schadenart | No | Optional: Schadenart / Unfalltyp (z. B. "Auffahrunfall") für den Kontext. | |
| schuldfrage | Yes | Schuldfrage des Nutzers: unverschuldet / teilschuld / selbst (eigenverschulden) / unklar. Erfrage sie vorher. |
| Name | Required | Description |
|---|---|---|
| hinweis | Yes | |
| ansprueche | Yes | |
| empfehlung | Yes | |
| schadenart | Yes | |
| eigenkosten | Yes | |
| schuldfrage | Yes | |
| anspruchslage | Yes | |
| abrechnungsweg | No | |
| naechster_schritt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the behavioral expectation that it ALWAYS offers the next step (assessor appointment or callback) and that such an offer is mandatory for a complete consultation. It also includes the disclaimer about not providing individual legal advice. This goes beyond the annotations without contradicting them.
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 description is two sentences but packed with relevant information: what it returns, the next steps, usage context, and a legal disclaimer. It is front-loaded with the core purpose and keeps the most important behavioral note (always offering next step) at the end. While not extremely short, it is efficient and well-structured.
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?
The tool has an output schema, so return values are covered elsewhere. The description covers the main claim categories, the fault-based differentiation, the mandatory next-step offering, and the disclaimer. It also instructs the agent to ask the fault question first and notes that the tool itself does not replace legal advice. This is complete for an agent to use correctly.
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 input schema has 100% description coverage, so all parameters (schuldfrage, vollkasko, schadenart) are documented. The description does not add new semantic meaning beyond what the schema provides; it only reinforces the need to ask schuldfrage, which is already in the schema. Baseline of 3 is appropriate because the schema carries the weight.
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 clearly states the tool's function: it delivers structured damage compensation claims based on fault (Wertminderung, Nutzungsausfall, etc.) and explicitly names the next-step tools (claimondo_finde_gutachter_termine, claimondo_melde_schaden). It distinguishes itself from siblings by focusing on claim information and consultation, not on booking or reporting actions.
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 explicitly says 'Nutze es für Beratungsfragen' and gives example queries. It instructs to ask the fault question first, and emphasizes that a consultation without offering an assessor appointment is incomplete. It also sets a boundary by stating it provides general information, not individual legal advice. This provides clear when-to-use guidance and anticipates follow-up steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fordert einen kostenlosen Telefon-Rückruf durch einen Claimondo-Berater an — der zweite Funnel-Arm neben claimondo_melde_schaden, für Kunden die lieber angerufen werden (oder wenn kein Slot passt / Daten fehlen). Legt einen Lead + Rückruf-Task in der Dispatch-Queue an; ein Berater meldet sich i. d. R. < 15 Min telefonisch.
Erfrage Name + Telefonnummer + (optional) Schadenart/Anliegen/PLZ. Rufe dies NUR mit einwilligung_erteilt=true auf, NACHDEM der Nutzer der Datenverarbeitung + dem telefonischen Kontakt (Verarbeitung teils über einen KI-Dienst in den USA) ausdrücklich zugestimmt hat.
| Name | Required | Description | Default |
|---|---|---|---|
| ort | No | Optional: Stadt/Adresse, falls keine PLZ bekannt. | |
| plz | No | Optional: PLZ, wo das Fahrzeug steht. | |
| name | Yes | Name des Kunden. | |
| telefon | Yes | Telefonnummer des Kunden für den Rückruf. | |
| anliegen | No | Optional: kurze Schilderung des Anliegens. | |
| schadenart | No | Optional: Schadenart / Unfalltyp für den Kontext. | |
| wunschzeit | No | Optional: Wunschzeit für den Rückruf (ISO-8601). Ohne → schnellstmöglich. | |
| einwilligung_erteilt | Yes | MUSS true sein. NUR setzen, nachdem der Nutzer der Datenverarbeitung + dem telefonischen Kontakt (Verarbeitung teils über einen KI-Dienst in den USA) ausdrücklich zugestimmt hat. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| wann | Yes | |
| status | Yes | |
| hinweis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (all false hints), so the description carries the full burden of disclosing side effects. It clearly states that the tool 'Legt einen Lead + Rückruf-Task in der Dispatch-Queue an' (creates a lead and callback task), indicating a write operation. It also discloses that processing is partly via an AI service in the USA, which is critical for consent/privacy. It additionally mentions the expected response time (<15 min). These are meaningful behavioral traits beyond what annotations provide, and there is no contradiction with annotations.
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 description is two well-structured paragraphs with no filler. The first sentence states the core purpose and differentiation; the second covers usage constraints and consent. Every sentence earns its place, and the critical consent requirement is front-loaded in the second paragraph. It is appropriately sized for the tool's complexity.
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?
Given the 8 parameters (3 required), 100% schema coverage, and an existing output schema, the description provides everything an agent needs: purpose, usage criteria, side effects, consent requirement, and a mention of the dispatch queue. It does not need to describe return values because the output schema handles that. The description is complete for correct invocation.
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%, so the baseline is 3. The description adds minimal extra meaning: it summarizes the required fields (Name + Telefonnummer) and mentions optional fields (Schadenart/Anliegen/PLZ), and reinforces the consent condition for einwilligung_erteilt. However, the schema already describes each parameter and the consent condition in detail. The description does not introduce new parameter semantics beyond what the schema already provides, so it stays at the baseline.
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 opens with a clear verb+resource: 'Fordert einen kostenlosen Telefon-Rückruf durch einen Claimondo-Berater an' (requests a free phone callback). It explicitly names the sibling tool 'claimondo_melde_schaden' as the alternative funnel arm, and distinguishes when to use this tool: for customers who prefer to be called or when no slot fits/data is missing. It also states the concrete side effect (creating a lead + callback task), so an agent can unambiguously tell this tool apart from its siblings without opening schemas.
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 provides explicit when-to-use guidance: it contrasts with claimondo_melde_schaden and gives the conditions for choosing this tool ('für Kunden die lieber angerufen werden (oder wenn kein Slot passt / Daten fehlen)'). It also states the hard prerequisite: must only be invoked with einwilligung_erteilt=true after user consent. No ambiguity remains about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sagt einen bereits gebuchten Kfz-Gutachter-Termin bei Claimondo ab — ohne Anruf beim Gutachter, ohne Login. Nutze dieses Tool, wenn ein Kunde sagt, dass er seinen Termin nicht wahrnehmen kann, absagen oder verschieben möchte.
Der Kunde nennt seine persönliche Fall-Referenz (den Token aus seinem Claimondo-Link, den er per WhatsApp erhalten hat) — die Referenz ist die Autorisierung.
Wirkung: der Termin wird freigegeben, Claimondo wird benachrichtigt und meldet sich für einen Ersatztermin. VERSCHIEBEN läuft genauso: erst hier absagen, dann über den persönlichen Claimondo-Link (oder claimondo_finde_gutachter_termine für einen neuen Vorschlag) einen neuen Termin wählen.
Args:
token (string): Die persönliche Fall-Referenz des Kunden.
grund (string, optional): Warum der Termin nicht passt.
Antwortet PII-frei (kein Name/Gutachter/Adresse). Mehrfach-Aufruf ist unschädlich: ein bereits abgesagter Termin wird nicht erneut geändert. Nicht raten/erfinden: ohne die vom Kunden genannte Referenz gibt es keine Absage.
| Name | Required | Description | Default |
|---|---|---|---|
| grund | No | Optionaler Grund der Absage (z. B. „krank", „Auto schon in der Werkstatt"). Hilft Claimondo, schneller einen Ersatztermin anzubieten. | |
| token | Yes | Die persönliche Fall-Referenz des Kunden (Token aus seinem Claimondo-Link / der WhatsApp-Nachricht). Der Kunde muss sie selbst nennen — nicht raten/erfinden. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| hinweis | Yes | |
| storniert | Yes | |
| warGeplant | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the call destructive and idempotent, and the description enriches this with concrete effects: the slot is released ('Termin wird freigegeben'), Claimondo is notified, responses are PII-free, and repeated calls are harmless because an already-cancelled appointment is not changed again. It also states the authorization requirement via the token.
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 action is front-loaded in the first sentence, and each subsequent block earns its place: trigger condition, token authorization, effect, reschedule flow, parameter recap, safety notes. Despite length, there is no 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?
For a destructive, authorization-gated tool, the description covers everything needed to call it correctly: who must supply the token, what happens on cancellation, idempotency, PII behavior, and the follow-up route for rescheduling. An output schema exists, so return-value details are not required here.
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 coverage is 100% and both parameter descriptions are already detailed, so the description adds little beyond the schema. It does frame the token as 'die Autorisierung' and repeats the no-guessing rule, but this is reinforcement rather than substantial new meaning.
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 opening sentence states the exact operation: 'Sagt einen bereits gebuchten Kfz-Gutachter-Termin bei Claimondo ab'. It also resolves the title's 'oder verschieben' by explaining that moving an appointment is done by cancelling here first and booking elsewhere.
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?
It gives an explicit trigger condition: 'Nutze dieses Tool, wenn ein Kunde sagt, dass er seinen Termin nicht wahrnehmen kann...' and directs to alternatives for the follow-up booking: the Claimondo link or 'claimondo_finde_gutachter_termine'. This tells the agent when and when not to use it.
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.
claimondo_melde_schaden3 fields changedInput schema / properties / email / descriptionPrevious value: -"E-Mail des Kunden — die Rückfallebene, wenn Telefon nicht trägt. IMMER MITERFRAGEN. Ohne sie ist der Vorgang verloren, sobald die Nummer kein WhatsApp/SMS empfängt (Festnetz, Zahlendreher, Nummer ohne WhatsApp) — der Kunde bekommt dann gar keinen Link und kommt nie in seinen Vorgang zurück. Freiwillig: Will der Nutzer keine angeben, trotzdem fortfahren."New value: +"E-Mail des Kunden — PFLICHTANGABE. Frage sie aktiv ab. Sie ist die Rückfallebene, wenn das Telefon nicht trägt: ohne sie ist der Vorgang verloren, sobald die Nummer kein WhatsApp/SMS empfängt (Festnetz, Zahlendreher, Nummer ohne WhatsApp) — der Kunde bekommt dann gar keinen Link. Will der Nutzer ausdrücklich keine angeben, sende exakt \"keine\" — dann übernimmt Dispatch den Anruf."Input schema / properties / email / formatRemoved value: -"email"Input schema / requiredPrevious value: -[
- "schadenart",
- "hergang",
- "plz",
- "name",
- "telefon",
- "einwilligung_erteilt"
-]New value: +[
+ "schadenart",
+ "hergang",
+ "plz",
+ "name",
+ "telefon",
+ "email",
+ "einwilligung_erteilt"
+]claimondo_melde_schaden3 fields changedInput schema / properties / einwilligung_erteilt / descriptionPrevious value: -"MUSS true sein und NUR nach ausdrücklicher Nutzer-Zustimmung gesetzt werden: Verarbeitung der Angaben + WhatsApp-Kontakt + Hinweis auf KI-Dienst/USA."New value: +"MUSS true sein und NUR nach ausdrücklicher Nutzer-Zustimmung gesetzt werden: Verarbeitung der Angaben + Kontakt per WhatsApp/SMS/E-Mail + Hinweis auf KI-Dienst/USA."Input schema / properties / emailAdded value: +{
+ "description": "E-Mail des Kunden — die Rückfallebene, wenn Telefon nicht trägt. IMMER MITERFRAGEN. Ohne sie ist der Vorgang verloren, sobald die Nummer kein WhatsApp/SMS empfängt (Festnetz, Zahlendreher, Nummer ohne WhatsApp) — der Kunde bekommt dann gar keinen Link und kommt nie in seinen Vorgang zurück. Freiwillig: Will der Nutzer keine angeben, trotzdem fortfahren.",
+ "format": "email",
+ "maxLength": 120,
+ "type": "string"
+}Input schema / properties / telefon / descriptionPrevious value: -"WhatsApp-Nummer des Kunden (für den FlowLink-Versand)."New value: +"Telefonnummer des Kunden für den FlowLink-Versand. Bevorzugt eine MOBILnummer — der Link geht zuerst per WhatsApp, dann per SMS. Eine Festnetznummer kann beides nicht empfangen; dann trägt nur die E-Mail."claimondo_termin_absagenclaimondo_finde_gutachter_termine1 field changedOutput schema / properties / gutachter / items / properties / termine / items / properties / buchungs_urlAdded value: +{
+ "type": "string"
+}claimondo_finde_werkstattclaimondo_pruefe_anspruch2 fields changedInput schema / properties / vollkaskoAdded value: +{
+ "description": "NUR bei schuldfrage=\"selbst\" auswerten: besteht eine Vollkasko? Davon haengt der ganze Weg ab — mit Vollkasko reguliert die eigene Versicherung (abzueglich Selbstbeteiligung), ohne zahlt der Halter selbst. NICHT raten: ohne diesen Wert liefert die Antwort ausdruecklich die Aufforderung, den Nutzer zu fragen.",
+ "enum": [
+ "ja",
+ "nein"
+ ],
+ "type": "string"
+}Output schema / properties / abrechnungswegAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}claimondo_finde_gutachter_termine1 field changedOutput schema / properties / gutachter / items / properties / buchungs_urlAdded value: +{
+ "type": "string"
+}claimondo_fall_statusclaimondo_finde_gutachter_termine6 fields changedInput schema / properties / ortAdded value: +{
+ "description": "Stadt/Adresse als Alternative zur PLZ, z. B. \"Köln\" oder \"Berlin Mitte\". PLZ ODER ort angeben.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / plz / descriptionPrevious value: -"5-stellige deutsche Postleitzahl, z. B. 50670 für Köln."New value: +"5-stellige deutsche Postleitzahl, z. B. 50670 für Köln. PLZ ODER ort angeben."Input schema / requiredRemoved value: -[
- "plz"
-]Output schema / properties / ortAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / standortAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "plz",
- "wunschtermin",
- "anzahl_gutachter",
- "gutachter",
- "interaktive_karte_url",
- "buchungs_telefon"
-]New value: +[
+ "plz",
+ "ort",
+ "standort",
+ "wunschtermin",
+ "anzahl_gutachter",
+ "gutachter",
+ "interaktive_karte_url",
+ "buchungs_telefon"
+]claimondo_finde_sachverstaendige6 fields changedInput schema / properties / ortAdded value: +{
+ "description": "Stadt/Adresse als Alternative zur PLZ, z. B. \"Köln\" oder \"Berlin Mitte\". PLZ ODER ort angeben.",
+ "maxLength": 120,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / plz / descriptionPrevious value: -"5-stellige deutsche Postleitzahl, z. B. 50670 für Köln."New value: +"5-stellige deutsche Postleitzahl, z. B. 50670 für Köln. PLZ ODER ort angeben."Input schema / requiredRemoved value: -[
- "plz"
-]Output schema / properties / ortAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / standortAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "plz",
- "radius_km",
- "anzahl_treffer",
- "sachverstaendige",
- "karte_url",
- "interaktive_karte_url",
- "buchungs_telefon"
-]New value: +[
+ "plz",
+ "ort",
+ "standort",
+ "radius_km",
+ "anzahl_treffer",
+ "sachverstaendige",
+ "karte_url",
+ "interaktive_karte_url",
+ "buchungs_telefon"
+]claimondo_rueckrufclaimondo_decode_briefclaimondo_melde_schaden3 fields changedInput schema / properties / slot_endAdded value: +{
+ "description": "Gewählter Slot-ENDE als ISO-8601 (gutachter[].termine[].end). Zusammen mit slot_start.",
+ "type": "string"
+}Input schema / properties / slot_startAdded value: +{
+ "description": "Gewählter Slot-START als ISO-8601 (gutachter[].termine[].start). Mit slot_end + sv_id → echte Termin-Reservierung.",
+ "type": "string"
+}Input schema / properties / wunschtermin / descriptionPrevious value: -"Gewählter Slot als ISO-8601 (gutachter[].termine[].start) — weicher Hold."New value: +"Optional: vager Wunschtermin (weicher Hold), falls KEIN konkreter Slot gewählt wurde."claimondo_pruefe_anspruchclaimondo_finde_gutachter_termineclaimondo_melde_schadenclaimondo_finde_sachverstaendigeAuto repair quote auditor, labor price benchmarks, and service deals for any US ZIP.
Auftraege, Rechnungen, Material und Zeiten eines Handwerksbetriebs abfragen und pflegen.
Waste collection dates for German addresses from municipal authority calendars.
Amtliche Bodenrichtwerte (BORIS) und Flurstücke (ALKIS) der Bundesländer zu einer Adresse.
Add one secure layer between your agents and this server.
