Skip to main content
Glama

Claimondo — Kfz-Gutachter finden & Termin buchen

Gutachter-Termin absagen oder verschieben

claimondo_termin_absagen
DestructiveIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
grundNoOptionaler Grund der Absage (z. B. „krank", „Auto schon in der Werkstatt"). Hilft Claimondo, schneller einen Ersatztermin anzubieten.
tokenYesDie persönliche Fall-Referenz des Kunden (Token aus seinem Claimondo-Link / der WhatsApp-Nachricht). Der Kunde muss sie selbst nennen — nicht raten/erfinden.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
hinweisYes
storniertYes
warGeplantYes

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: '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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool maps to a distinct stage of the customer journey: researching appraisers, searching workshops, decoding insurer letters, assessing claims, registering a case, requesting a callback, or checking case status. The only near-overlap—finde_gutachter_termine versus finde_sachverstaendige—is actively clarified within the descriptions, so an agent can confidently disambiguate.

Naming Consistency4/5

All tools share the claimondo_ prefix and use snake_case, which makes the set feel consistent. However, most tools follow a verb_object pattern (decode, finde, melde, pruefe, rueckruf), while fall_status is a noun phrase and rueckruf is a noun, creating a minor stylistic deviation.

Tool Count5/5

With 8 tools, the server is well-scoped for its purpose: searching, assessing, creating leads, and retrieving status. Each tool covers a meaningful part of the claims funnel without redundancy or bloat.

Completeness4/5

The tool set covers the main flow from finding an appraiser or workshop, to assessing claim rights, to creating a lead via claim submission or callback, and later checking status. There is no dedicated tool for rescheduling or cancelling a booked appointment, but that part is intentionally handled outside the MCP via the customer's FlowLink, so the core domain surface is solid.

Resources