Findet Kfz-Gutachter in Deutschland, zeigt freie Termine und bucht den Besichtigungstermin.
Scored across 9 tools
Most tools have clear roles, but claimondo_finde_gutachter_termine and claimondo_finde_sachverstaendige overlap heavily: both search for the same type of expert by PLZ and differ mainly in whether concrete bookable slots are returned. The legal-advisory tools also share a similar 'rights + next step' pattern, though their input triggers are distinguishable.
All tools share the claimondo_ prefix and mostly use snake_case imperative verb-noun names like decode_brief, finde_werkstatt, melde_schaden, and pruefe_anspruch. A few entries deviate from the verb-first pattern, notably fall_status and rueckruf, so the naming is consistent but not perfectly uniform.
Nine tools is a well-scoped size for this funnel: expert search, workshop search, legal orientation, lead creation, callback, status checks, and cancellation are all covered without excessive granularity. The count feels right for the server's purpose.
The lifecycle is largely complete: find experts and workshops, assess claims, decode insurer letters, create a booking lead, check status, and cancel appointments. The main gap is that the final booking itself is handed off to the customer's flow link rather than fully executed inside the tool set, and rescheduling is only handled indirectly via cancel + rebook.
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 establish readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond that: it is general information, not individual legal advice, and it must always include an offer for an independent expert appointment or callback. This helps the agent set user expectations correctly.
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 every part earns its place: the phrase examples, the legal disclaimer, and the required follow-up are all actionable. It is front-loaded with the core purpose and uses parenthetical examples efficiently, though it could be slightly tightened.
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 a single parameter, rich annotations, and an existing output schema, the description covers everything an agent needs: what input to supply, what the tool does, what follow-up tools to reference, and the important scope limitation. Nothing critical 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?
The schema description covers 100% of the single parameter and already defines 'text' as the letter text or relevant excerpt. The description reinforces this instruction, but adds only marginal value beyond the schema because it does not introduce new parameter constraints or format requirements.
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: it decodes letters from the opposing motor-liability insurer and recognizes common claim-reduction phrases. It also lists concrete examples of patterns and clearly distinguishes this tool from siblings like finde_werkstatt or melde_schaden.
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 states clearly when to use the tool: when a user has a letter from the opposing Kfz-Haftpflichtversicherung and needs it decoded. It also gives operational guidance, such as passing the text or a relevant excerpt and always offering next steps, but it does not explicitly describe when not to use it or name alternatives in a conditional way.
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, the description discloses key behaviors: the token itself is the authorization, the tool is read-only, it intentionally returns only a coarse status label and no personal data, and invalid/unknown references yield 'kein Fall gefunden'. It also explicitly warns against guessing or inventing a status, which is highly valuable for an agent.
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 front-loaded with purpose and context, and every major point earns its place: token provenance, authorization, read-only behavior, no-PII guarantee, and error handling. The redundant 'Args' block repeats the schema but is small and does not significantly hurt 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 single-parameter read-only status lookup with an output schema, the description is complete. It tells the agent when to use it, how to obtain the token, what the tool will and will not return, and how invalid references behave. No critical operational detail 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?
The input schema already fully documents the token parameter and its description, giving a baseline of 3. The description adds meaningful context by explaining the token's provenance (Claimondo link received via WhatsApp) and its role as authorization, which goes beyond the schema. However, it does not provide format examples, length constraints, or pattern details.
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 action and resource: returning the rough processing status of a previously reported claim. It clearly ties the tool to cases created via claimondo_melde_schaden/claimondo_rueckruf and explicitly frames it for the customer question 'wo steht mein Fall?', which distinguishes it from siblings like claimondo_pruefe_anspruch.
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 a clear condition for use: a returning customer asking about case status and providing their personal reference token. It implies when not to use it (when no token is available) but does not explicitly name alternative tools or exclusion criteria, so it falls short of full guidance.
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?
The description states it is read-only and anonymous, and explicitly says 'legt nichts an und meldet keinen Schaden', which adds a behavioral dimension beyond the raw annotations. It also reveals key nuances: wunschtermin only influences slot ranking rather than acting as a hard filter, and an older API version may lack buchungs_url with the map as fallback path. These are non-obvious behavioral facts an agent needs to know.
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?
Though the description is longer than average, it earns its length: sections are organized with headings/paragraphs, front-loaded with purpose and sibling contrast, and every paragraph adds either selection guidance, response-shape context, or critical link behavior that is absent from the structured data. The 'WICHTIG' and 'Hinweis' blocks are particularly high-value operational guidance.
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 includes the full output/return shape, explains the ranking-affecting nature of wunschtermin, gives a practical when-to-use example, and documents two URL-ownership situations that could easily cause user-facing errors. It even states how the tool relates to claimondo_melde_schaden via gutachter[].id plus termin.start. For a 4-parameter search tool, this is complete and decision-relevant.
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 Args section largely restates the schema definitions (format, required-alternative relation between plz and ort, wunschtermin semantics, response_format). It does not add meaningfully new parameter semantics beyond what the schema already documents. The optional-plz/ort interplay is mentioned in both the schema and the description, but there is no extra contract detail.
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 explicitly distinguishes itself from the sibling claimondo_finde_sachverstaendige, which returns only an anonymized list. An agent can immediately tell what this tool does and how it differs from its nearest alternative.
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 clear when-to-use guidance: 'Nutzer will einen Gutachter-Termin sehen/vergleichen'. It also names the sibling alternative and the condition that selects it — claimondo_finde_sachverstaendige for an anonymized list, this tool for bookable experts with concrete free slots. Additional practical guidance (link buchungs_url, do not link interaktive_karte_url when recommending one expert, use the map only for 'show all nearby') further clarifies correct usage.
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=true, idempotentHint=true, destructiveHint=false. The description reinforces this with 'Read-only und anonym' and adds behavioral details like returning a distance-sorted list, map image URL, and callback phone number. It does not contradict annotations. A minor gap is no mention of rate limits or auth, but given the tool's nature, this is acceptable.
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-structured with clear sections: purpose, read-only note, args, returns, usage. It is concise without being overly terse; every sentence adds value. Could be slightly more streamlined, but overall effective.
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 tool has 4 parameters and an output schema, the description provides a complete overview: what it does, inputs, output structure, and when to use. It lacks error handling details, but as a finder tool this is sufficient. The output schema is explicitly described in the 'Returns' section.
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 all parameters. The description's 'Args' section repeats most schema descriptions and adds examples (e.g., '50670'). It clarifies that PLZ OR ort must be provided, which is a slight addition. Baseline 3 is appropriate.
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 title and description clearly state it finds certified Kfz experts near a German postal code. The verb 'finde' and resource 'Sachverstaendige' are specific, and the description distinguishes from siblings like 'finde_gutachter_termine' (which finds appointment slots) and 'melde_schaden' (report damage).
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?
Explicit 'Use when' and 'Nicht für' sections provide clear guidance on when to use this tool (user asks for a car expert) and when not to (reporting damage, booking appointments). This helps the agent select the right tool among siblings.
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?
Annotations declare readOnly/openWorld/idempotent/non-destructive, and the description adds the crucial behavioral detail that the output deliberately omits company names, phone numbers, and addresses, instead requiring the agent to link the user to werkstatt_finder_url. It also warns against inventing names or contact data. This is a meaningful transparency beyond the structured 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 well structured with clear headings, short bullets, and an early explanatory section. Every paragraph earns its place: purpose, routing logic, argument details, and output behavior. The tone is dense but not bloated, and the most important information is 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?
For a read-only, 4-parameter lookup tool, the description covers the complete flow: when to call, which arguments to provide, and what to do with the output. It also addresses edge cases like unclear fault and how to present results without fabricating data. The few implicit details (e.g., that plz/ort are mutually required in practice) are strongly implied by 'PLZ ODER ort angeben.'
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?
Only 25% of the schema parameters have descriptions, but the description's Args section compensates well. It explains PLZ is a 5-digit German postal code, gives an example, explicitly says 'PLZ ODER ort angeben' (provided the relationship between the two), and documents radius range/default and response_format choices. This is substantially more meaningful than the raw 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 opening sentence states a specific action and resource: 'Findet Claimondo-Partner-Werkstätten im Umkreis einer deutschen Postleitzahl.' It clearly identifies the tool's scope and, through the later routing guidance, explicitly distinguishes it from claimondo_finde_gutachter_termine. This makes the purpose and sibling differentiation immediately clear.
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 guidance: use it first for selbstverschuldete Schäden, use claimondo_finde_gutachter_termine first for unverschuldete Schäden, and use claimondo_pruefe_anspruch when the fault is unclear. It names alternatives, provides the ordering of steps, and explains why, so an agent can correctly select and sequence this tool.
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. | |
| 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 | WhatsApp-Nummer des Kunden (für den FlowLink-Versand). | |
| 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 + WhatsApp-Kontakt + 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?
Discloses key behaviors beyond annotations: it's a write action ('ERZEUGT EINEN LEAD'), sends WhatsApp, requires consent, and returns no link/PII. Annotations already indicate non-readOnly, and description adds critical context about side effects and data handling.
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?
Well-structured with bold headings and warnings, but somewhat verbose. Every sentence adds value, though some repetition (e.g., consent explanation). Front-loaded with purpose and warnings, then flow and return values.
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 complexity (10 params, 6 required, output schema exists), description covers prerequisites, workflow, behavior, and return format. It explicitly states what the output contains and what it does not contain, making it complete for an AI agent.
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 baseline is 3. Description adds value by explaining the purpose of slot parameters and the consent parameter in the context of the workflow. It clarifies the relationship between sv_id, slot_start, slot_end, and wunschtermin, which aids correct usage.
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?
Description clearly states the primary action ('Meldet einen Kfz-Schaden und stößt die Gutachter-/Termin-Buchung an') and distinguishes from siblings by outlining the prerequisite step (claimondo_finde_gutachter_termine) and the resulting action (sending FlowLink). It uses specific verbs and resources.
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?
Provides explicit when-to-use guidance: after finding surveyor and obtaining consent. Warns about what not to do (no legal advice). Includes step-by-step workflow and explicitly mentions conditions for calling the tool (einwilligung_erteilt must be true).
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?
The description adds significant behavioral context beyond the readOnly/idempotent annotations: the tool always produces a follow-up action (Gutachter offer or callback), requires the Schuldfrage to be asked first, and explicitly disclaims individual legal advice. This makes the agent's side effects and conversational expectations clear.
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 front-loaded with the core purpose and then adds workflow and legal caveats. It is slightly longer than strictly necessary, with minor redundancy between 'IMMER den nächsten Schritt' and 'Eine Beratung ohne Angebot ... ist unvollständig', but every sentence contributes useful guidance.
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 output schema, complete parameter descriptions, and annotations, the description covers the tool's behavior, prerequisites, limitations, and downstream tool routing. Nothing essential for calling the tool correctly appears to be 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%, and the schema already documents schuldfrage, vollkasko, and schadenart with their enum constraints and special rules. The description reinforces that Schuldfrage must be asked first but does not add new semantic detail beyond 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 description names the exact deliverable (structured Schadensersatz-Ansprüche nach Schuldfrage), legal basis, and the mandatory next step of offering a Gutachter. It is clearly distinct from siblings like claimondo_finde_gutachter_termine because it is positioned as a Beratung tool that produces claims and then routes to next 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?
It explicitly says to use the tool for Beratungsfragen like 'welche Ansprüche habe ich' and instructs the agent to ask the Schuldfrage first. It also states that a consultation without offering a Gutachter is incomplete. However, it does not explicitly state when not to use it compared with siblings such as claimondo_fall_status or claimondo_decode_brief.
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?
Beyond the annotations, the description reveals concrete side effects: a lead and callback task are created in the dispatch queue, and an advisor usually calls back within 15 minutes. It also discloses the US-based AI processing detail, which is critical for consent handling and matches the tool's non-readonly 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 information-dense but efficient: the primary purpose is front-loaded, side effects and timing are stated in the first paragraph, and the consent prerequisite is given in the second. Every sentence earns its place and 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?
The tool has an output schema, so return-value details are not required. The description fully covers the essential context: what the tool does, when to use it, what side effects occur, the expected callback timeframe, and the mandatory consent condition. Nothing critical 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?
The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds extra semantic value by emphasizing that einwilligung_erteilt must be true, marking which fields are optional, and explaining that wunschzeit without a value means 'as soon as possible'.
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 action and resource: it requests a free callback from a Claimondo advisor and creates a lead plus callback task. It explicitly positions itself as the second funnel arm next to claimondo_melde_schaden, so the agent can distinguish it from the main sibling tool.
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 clearly tells when to use this tool: when customers prefer being called, when no slot fits, or when data is missing. It also gives a firm precondition: only invoke with einwilligung_erteilt=true after the user has explicitly consented to data processing and phone contact, including the US AI service.
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?
The description goes well beyond the annotations by explaining the authorization model (token is the authorization), the effect (appointment released, Claimondo notified), idempotency ('Mehrfach-Aufruf ist unschädlich'), and PII-free responses. It also clarifies the destructive nature in a nuanced way, consistent with destructiveHint=true.
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 somewhat long but each part earns its place: purpose, usage trigger, workflow, args, safety notes, and idempotency. The Args section partially repeats schema info, but it is compact and the critical operational guidance is 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?
For a tool with two parameters, a clear destructive action, and no need to document return values (output schema exists), the description covers all essential context: when to use, how to authorize, what happens, idempotency, and what not to do. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by framing the token as the authorization ('die Referenz ist die Autorisierung') and by emphasizing not to guess or invent it. This goes slightly beyond the schema's field descriptions.
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 and resource: 'Sagt einen bereits gebuchten Kfz-Gutachter-Termin bei Claimondo ab'. It also clarifies the scope (no call, no login) and the rescheduling pathway, making it easy to distinguish from sibling tools like claimondo_finde_gutachter_termine.
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?
Explicitly states when to use the tool ('wenn ein Kunde sagt, dass er seinen Termin nicht wahrnehmen kann, absagen oder verschieben möchte') and describes the rescheduling alternative: cancel here, then use the personal Claimondo link or claimondo_finde_gutachter_termine. This gives clear decision guidance.
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_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_sachverstaendigeAuftraege, Rechnungen, Material und Zeiten eines Handwerksbetriebs abfragen und pflegen.
Waste collection dates for German addresses from municipal authority calendars.
Find participating local service providers and book live appointment times.
Validiert E-Rechnungen (ZUGFeRD/Factur-X, XRechnung) gegen EN 16931 mit Korrekturvorschlägen.
Add one secure layer between your agents and this server.
