Insurers Global

Get one market with its full insurer list

get_country

Read-onlyIdempotent

Get one country in Africa, Europe, Asia-Pacific, South America or North America: regulator (name, acronym, website, notes), currency, counts by class and ownership, verification status against the regulator register, market notes, and its licensed insurers with register identifiers and source caveats. Counts by class count entities, not licences: every company appears once, under the class its register row records, and byClass sums to total. A regulator’s own per-class licence tally is broader and will not match. Most markets return every insurer in one call; a large market returns a first page, and insurersPage gives the total and the nextOffset to pass as offset. Prefer get_country_summary for market facts alone.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum entity rows to return. Long lists also stop early to keep the response small; the page object reports total and nextOffset.
`offset`	No	Entity rows to skip, for paging.
`compact`	No	true: return each insurer as a lean row (slug, name, country, class, groupSlug, verification) without notes, source text, identifiers or links, so more rows fit in one response. get_insurer returns the full record for any slug.
`country`	Yes	Country slug (e.g. "micronesia") or ISO alpha-2 code (e.g. "FM").

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No
`error`	No
`dataset`	No
`licence`	No
`version`	No	Dataset version the result was read from.
`verified`	No	Date the dataset snapshot was verified.
`retryable`	No
`verificationNote`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 27, 2026

changedInput schema / properties / country / description

Previous value: -"Country slug (e.g. \"uganda\") or ISO alpha-2 code (e.g. \"UG\")."New value: +"Country slug (e.g. \"micronesia\") or ISO alpha-2 code (e.g. \"FM\")."

Changed3 schema fields changedSep 23, 2026

addedInput schema / properties / compact

Added value: +{
+  "default": false,
+  "description": "true: return each insurer as a lean row (slug, name, country, class, groupSlug, verification) without notes, source text, identifiers or links, so more rows fit in one response. get_insurer returns the full record for any slug.",
+  "type": "boolean"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 200,
+  "description": "Maximum entity rows to return. Long lists also stop early to keep the response small; the page object reports total and nextOffset.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Entity rows to skip, for paging.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

Changed1 schema field changedSep 23, 2026

changedInput schema / properties / country / description

Previous value: -"Country slug (e.g. \"egypt\") or ISO alpha-2 code (e.g. \"EG\")."New value: +"Country slug (e.g. \"uganda\") or ISO alpha-2 code (e.g. \"UG\")."

Changed1 schema field changedSep 23, 2026

changedInput schema / properties / country / description

Previous value: -"Country slug (e.g. \"malaysia\") or ISO alpha-2 code (e.g. \"MY\")."New value: +"Country slug (e.g. \"egypt\") or ISO alpha-2 code (e.g. \"EG\")."

Changed1 schema field changedSep 17, 2026

changedInput schema / properties / country / description

Previous value: -"Country slug (e.g. \"ghana\", \"france\") or ISO alpha-2 code (e.g. \"GH\", \"FR\")."New value: +"Country slug (e.g. \"malaysia\") or ISO alpha-2 code (e.g. \"MY\")."

First observedSep 14, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds significant non-obvious behavioral context: counts count entities not licences, byClass sums to total, the regulator's own licence tally will not match, and large markets return a first page rather than the full list. These are exactly the quirks an agent needs to interpret results correctly.

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?

Five sentences, each earning its place: scope, count semantics, regulator mismatch warning, pagination behavior, and sibling routing. The core purpose is front-loaded in the first sentence, and there is no filler, repetition of schema content, or annotation duplication.

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 rich output schema (which covers return structure), the 100% parameter schema coverage, and strong annotations, the description covers everything an agent needs: what data comes back, how counts should be interpreted, how to page, and which sibling to use instead. No gaps remain for correct invocation.

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. The description adds value by explaining how offset interplays with the response (insurersPage.total and nextOffset to pass as offset), giving operational meaning beyond the schema's dry "Entity rows to skip" text. The compact and country parameters are already well documented in the schema, so the description need not repeat them.

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 opens with a specific verb+resource ("Get one country") and enumerates exactly what is returned: regulator details, currency, counts, verification status, market notes, and licensed insurers with register identifiers. It clearly differentiates from siblings by naming get_country_summary for facts-only use and implicitly distinguishing from get_insurer (full insurer records are per-slug there).

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?

The description gives explicit routing guidance: "Prefer get_country_summary for market facts alone" directly tells the agent when this tool is NOT the right choice. It also explains the pagination usage pattern (insurersPage returns nextOffset to pass as offset) and when a single call suffices versus when paging is required, leaving nothing to inference.

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

All Insurers Global 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?