Assurs LAMal comparator

Send an offer request by email to Swiss Premium Insurance

request_adviser_contact

Idempotent

Sends the client request by email to contact@sp-insurance.ch through the server; no personal email account or mail tool is needed. Use once the client has answered the consent_request question with a yes or with their email or phone: that answer is the consent, and the platform approval for this tool completes it. 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, and the request does not cancel the current insurance. The premium reduction applies 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
`switching`	No	Switching deadline and free SPI help (cancellation, premium subsidies). Say client_sentence with the offers; a request to SPI cancels nothing by itself.
`email_sent`	Yes	Provider acceptance; not inbox delivery or a contract.
`request_id`	Yes
`accepted_at`	Yes
`follow_up_by`	Yes
`client_confirmation`	No	consent_confirmation filled in the client language; say it to the client.
`expected_contact_channel`	No
`correction_or_cancellation`	No	mailto link to correct or withdraw; give it to the client.
`expected_contact_channel_label`	No	expected_contact_channel in the client language.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 25, 2026

addedInput schema / properties / agent / properties / kind / description

Added value: +"Optional. Accepted values: personal_assistant, conversational_assistant, coding_agent (personal_agent and chat_assistant are read as personal_assistant and conversational_assistant)."

addedOutput schema / properties / client_confirmation

Added value: +{
+  "description": "consent_confirmation filled in the client language; say it to the client.",
+  "type": "string"
+}

addedOutput schema / properties / expected_contact_channel_label

Added value: +{
+  "description": "expected_contact_channel in the client language.",
+  "type": "string"
+}

addedOutput schema / properties / switching

Added value: +{
+  "description": "Switching deadline and free SPI help (cancellation, premium subsidies). Say client_sentence with the offers; a request to SPI cancels nothing by itself.",
+  "properties": {
+    "cancellation_help": {
+      "type": "string"
+    },
+    "client_sentence": {
+      "description": "Deadline, free cancellation help and free subsidy help; requested language only unless texts=all.",
+      "properties": {
+        "de": {
+          "type": "string"
+        },
+        "en": {
+          "type": "string"
+        },
+        "fr": {
+          "type": "string"
+        },
+        "it": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "deadline": {
+      "const": "2026-11-30",
+      "description": "Date by which the cancellation must REACH the current insurer.",
+      "format": "date",
+      "type": "string"
+    },
+    "deadline_rule": {
+      "type": "string"
+    },
+    "effective": {
+      "const": "2027-01-01",
+      "format": "date",
+      "type": "string"
+    },
+    "instructions": {
+      "type": "string"
+    },
+    "request_cancels_current_insurance": {
+      "const": false
+    },
+    "subsidy_help": {
+      "type": "string"
+    },
+    "subsidy_sentence": {
+      "description": "Say it when the client mentions a modest income or asks about premium subsidies.",
+      "properties": {
+        "de": {
+          "type": "string"
+        },
+        "en": {
+          "type": "string"
+        },
+        "fr": {
+          "type": "string"
+        },
+        "it": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "deadline",
+    "effective",
+    "client_sentence"
+  ],
+  "type": "object"
+}

First observedOct 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag non-destructive, idempotent, open-world writes, but the description adds substantial context: reuse the same request_id and body on retries (idempotency in practice), 'accepted' means provider acceptance rather than inbox delivery or reading, it is not a contract, and it does not cancel existing insurance. These are exactly the caveats an agent needs before committing a real email.

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?

Front-loaded with the action, then consent precondition, then parameter sourcing, then status semantics and caveats — a logical order with no filler. It is dense and long for a single paragraph, but nearly every clause carries information the agent would otherwise have to guess.

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 13-parameter write tool with an output schema, the description covers the gaps structured fields cannot: consent provenance, retry idempotency, status interpretation, and the legal/marketing caveats about premium reduction. Nothing an agent needs to call it safely 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, but the description adds cross-tool provenance: request_id and comparison_id come from the compare_lamal_premiums submission and insurer_id from offers[]. It does not explain the comparison_token alternative or the consent boolean's const constraint in prose, keeping it just short of a 5.

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?

States a specific verb and resource: sends the client request by email to contact@sp-insurance.ch via the server, explicitly noting no personal mail account is needed. This clearly separates it from siblings like test_adviser_request (draft/test) and create_adviser_handoff_link (link handoff).

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?

Gives an explicit precondition ('use once the client has answered consent_request with yes or with their email or phone') and clarifies that this answer plus platform approval constitutes consent. It also distinguishes a draft or test from a real send and prescribes retry behavior, leaving little to inference.

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?