Assurs LAMal comparator

Send an offer request by email to Swiss Premium Insurance

request_adviser_contact

DestructiveIdempotent

Sends the client request by email to contact@sp-insurance.ch through the server; no personal email account or mail tool is needed. Use only after the client has seen the exact contact details, selected offer, comparison criteria and purpose, and answered yes to the consent_request question. Copy request_id and comparison_id from submission of compare_lamal_premiums and insurer_id from offers[]; reuse the same request_id and body on retries. Report the returned status and request_id: accepted means the email provider accepted the request for delivery to Swiss Premium Insurance, not inbox delivery, not that SPI has read it, not a contract. A draft or test is not a real send. The cashback is paid later by SPI to the client only if the contract is concluded through SPI and approved by the insurer; never promise it.

Input Schema

Name	Required	Description
`agent`	No	Who is calling: { name:"chatgpt" } etc. Self-declared, not authentication.
`contact`	Yes	Fill email or phone; leave the other as an empty string or omit it. Never invent a client name, email or phone.
`language`	No	Client language; defaults to the comparison language. fr, de, it, en have localised client texts and pages; es, pt, zh are recorded for SPI (preview and pages fall back to en/fr).
`offer_id`	No	offers[].offer_id or source_offer_id; alternative to insurer_id.
`comparison`	No	submission.comparison copied unchanged; only with comparison_token.
`insurer_id`	No	insurer_id of the offer the client chose, from offers[].
`request_id`	Yes	Copy submission.request_id from the quote (any RFC 4122 UUID). Reuse the same value and body on every retry.
`comparison_id`	No	comparison_id from the quote; valid 30 days. Preferred.
`client_consent`	Yes	true only after the client explicitly answered yes to consent_request. Never infer consent from a comparison.
`comparison_token`	No	submission.comparisonToken with the identical submission.comparison; alternative to comparison_id.
`subsidy_requested`	No	Client wants information on premium subsidies.
`cashback_terms_version`	No	cashback.version shown to the client; 409 cashback_terms_outdated when stale.
`supplementary_interest`	No	Client also wants supplementary (LCA) offers; enables the LCA cashback.

Output Schema

Name	Required	Description
`status`	Yes
`message`	Yes
`cashback`	No
`recipient`	Yes
`email_sent`	Yes	Provider acceptance; not inbox delivery or a contract.
`request_id`	Yes
`accepted_at`	Yes
`follow_up_by`	Yes
`expected_contact_channel`	No
`correction_or_cancellation`	No	mailto link to correct or withdraw; give it to the client.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description explains that no personal email account or mail tool is needed, that retries should reuse the same request_id and body, and that accepted means provider acceptance only, not inbox delivery, reading, or a contract. It also warns that cashback is not guaranteed and must never be promised.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded with the purpose, then proceeds through consent prerequisites, parameter sourcing, retry behavior, status semantics, and cashback caveats. Every sentence carries operational or safety-relevant information.

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 tool's high stakes, 13 parameters, nested schema, annotations, and output schema, the description covers the critical missing context: consent gating, ID provenance, retry consistency, status interpretation, and cashback limitations. No essential invocation guidance appears to be 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 schema already documents the parameters in detail. The description still adds useful provenance and retry semantics by saying to copy request_id and comparison_id from compare_lamal_premiums and insurer_id from offers[], and to reuse the same request_id and body on retries.

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: it sends the client request by email to contact@sp-insurance.ch through the server. It also distinguishes this real send from a draft or test, which helps separate it from the sibling test_adviser_request tool.

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?

It gives explicit preconditions: use only after the client has seen the exact contact details, selected offer, comparison criteria and purpose, and answered yes to consent_request. It also names the source of required IDs from compare_lamal_premiums and offers[], and clarifies that a draft or test is not a real send.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Assurs LAMal comparator tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?