Zorgverzekering.chat: Dutch health insurance

Search basic health insurance policies

zoek_basisverzekeringen

Read-onlyIdempotent

Searches Dutch basic health insurance policies (basisverzekering) for an insurance year. Returns per policy the premium per month and per year at the chosen voluntary deductible (vrijwillig eigen risico), the policy type, freedom of choice of care providers (zorgkeuze, based on reimbursement of non-contracted care, niet-gecontracteerde zorg), customer rating, a link to the policy page (detailUrl; afsluitUrl is only filled over the REST API) and source ids. Filter by policy type, insurer, minimum reimbursement for non-contracted care and care type (zorgsoort); sort by premie, zorgkeuze or rating and always tell the user the sort key (meta.sorteersleutel). The insured care itself is the same in every basic policy by law; policies differ in premium and choice of providers. Paginated with limit and cursor. Provides information, not advice: the user makes the decision and signs up with the insurer themselves.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "jaar": "<jaar>"
    },
    "name": "zoek_basisverzekeringen"
  }
}

Input Schema

Name	Required	Description	Default
`jaar`	Yes	Insurance year (verzekeringsjaar), e.g. 2027. During the switching season (November-December) users usually mean the coming year.
`taal`	No	Response language: nl (Dutch, default) or en (English).	nl
`type`	No	Policy type: natura (only contracted care fully reimbursed), restitutie (free choice of provider), combinatie (mix), budget (lowest premium, limited choice).
`limit`	No	Maximum number of results per page (1-50, default 10).
`cursor`	No	Opaque pagination cursor: pass meta.cursor from the previous response to get the next page.
`sorteer`	No	Sort order: premie (lowest annual premium first, default), zorgkeuze (most freedom of choice first), rating (highest customer rating first).	premie
`zorgsoort`	No	Type of care (zorgsoort), lowercase key such as 'ziekenhuis' (hospital), 'kliniek', 'ggz' (mental healthcare), 'fysio', 'wijkverpleging', 'apotheek'.
`eigenRisico`	No	Voluntary deductible (vrijwillig eigen risico) in whole euros used to price the premium: 0 (default), 100, 200, 300, 400 or 500. It comes on top of the mandatory deductible (verplicht eigen risico).	0
`verzekeraarId`	No	Insurer id (verzekeraar), e.g. 'vgz', as returned by list_verzekeraars.
`minVergoedingNietGecontracteerd`	No	Minimum reimbursement percentage (0-100) for care from non-contracted providers (niet-gecontracteerde zorg). Applies to zorgsoort if given, otherwise to every care type of the policy.

Output Schema

Name	Required	Description	Default
`data`	Yes
`meta`	Yes
`acties`	Yes
`bronnen`	Yes
`aannames`	Yes
`samenvatting`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower, yet the description adds real context: pagination via limit/cursor, that premium is priced at the chosen voluntary deductible, that afsluitUrl is only populated over the REST API, and the meta.sorteersleutel disclosure obligation. The main omission is that it does not warn about the response size or the consequences of a large limit beyond the paginated note.

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 purpose, then results, then filtering/sorting, then the advisory disclaimer, so the most important information comes first. It is a single dense paragraph with some unavoidable jargon repetition of schema field names, but no sentence is truly wasted; splitting into short bullets would improve scanability slightly.

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 10-parameter search with an output schema and full annotations, the description supplies everything still needed to call it correctly: deductible-driven pricing, pagination contract, sort-key reporting, domain caveat that covered care is identical by law, and the non-advisory stance. Return-value details are already in the output schema, and the extra mention of afsluitUrl is a useful quirk rather than redundancy.

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 baseline is 3, but the description adds meaning beyond the schema: eigenRisico is described as the basis for premium pricing and as stacking on the mandatory deductible, minVergoedingNietGecontracteerd is explained as applying to zorgsoort when given and otherwise to all care types, and zorgkeuze is defined via reimbursement of non-contracted care. These are semantic clarifications the enum/description fields only partially convey.

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?

Opens with a specific verb and resource ('Searches Dutch basic health insurance policies (basisverzekering) for an insurance year') and scopes it to basic policies only, implicitly distinguishing it from zoek_aanvullende_pakketten and vergelijk_polissen. It also states what the search actually varies on (premium and provider choice, not covered care), so an agent understands the differentiator without opening a schema.

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?

Gives concrete usage context: filter by type, insurer, reimbursement and zorgsoort, sort by one of three keys, and always report the sort key to the user. It also sets an explicit boundary ('Provides information, not advice: the user makes the decision and signs up with the insurer themselves'). It never names sibling tools like vergelijk_polissen or bereken_jaarkosten as alternatives, so routing between tools is left to inference.

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

All Zorgverzekering.chat: Dutch health insurance 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.