Skip to main content
Glama

Claimondo — Kfz-Gutachter finden & Termin buchen

Ansprüche prüfen (Beratung) + Gutachter anbieten

claimondo_pruefe_anspruch
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vollkaskoNoNUR 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.
schadenartNoOptional: Schadenart / Unfalltyp (z. B. "Auffahrunfall") für den Kontext.
schuldfrageYesSchuldfrage des Nutzers: unverschuldet / teilschuld / selbst (eigenverschulden) / unklar. Erfrage sie vorher.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hinweisYes
anspruecheYes
empfehlungYes
schadenartYes
eigenkostenYes
schuldfrageYes
anspruchslageYes
abrechnungswegNo
naechster_schrittYes

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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