Assurs LAMal comparator

Validate a request without sending

test_adviser_request

Read-onlyIdempotent

Harmless integration test with the same body as request_adviser_contact: validates the request and returns a preview with status validated_test and email_sent false. Use synthetic contact details only. No commercial lead, email, entitlement or payment. Never describe this as a real submission.

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
`preview`	Yes	What a real send would contain.
`recipient`	Yes
`email_sent`	Yes
`request_id`	Yes
`payment_created`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 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 / preview / properties / consent_confirmation

Added value: +{
+  "description": "The confirmation a real send returns, filled.",
+  "type": "string"
+}

addedOutput schema / properties / preview / properties / household_monthly_chf
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / preview / properties / members_count
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / preview / properties / model_name_official
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / preview / properties / people

Added value: +{
+  "description": "Household only: each member with model and monthly premium.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / preview / properties / premium_monthly_chf / description
```
Added value: +"Monthly premium; for a household the household total."
```

First observedOct 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, and the description adds concrete behavioral details: it validates, returns status validated_test, sets email_sent false, creates no lead/email/entitlement/payment, and requires synthetic data. This is richer than what the annotations alone convey and is fully consistent with them.

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?

Three short sentences, front-loaded with what the tool is and what it returns, then the safety constraints. Every sentence adds useful information and nothing is wasted.

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 read-only test endpoint with a full input schema, complete annotations and an output schema, the description covers purpose, return status, side-effect boundaries and data constraints. Nothing needed 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 13 parameters are already documented in the schema. The description adds only the high-level contract that the body matches request_adviser_contact and that contact details must be synthetic, without further parameter-specific meaning.

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: an integration test that validates a request body and returns a preview. It explicitly distinguishes itself from the sibling request_adviser_contact by saying it uses the same body but sends no email.

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?

Clearly indicates this is for integration testing with synthetic contact details only, and explicitly says never to describe it as a real submission. It implies the real-submission alternative is request_adviser_contact, though it does not spell out the when-to-use rule in a separate sentence.

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?