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. "uganda") or ISO alpha-2 code (e.g. "UG").

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.

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.7/5.0

Behavior5/5

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

The description discloses a non-obvious counting behavior: 'Counts by class count entities, not licences' and 'byClass sums to total.' It also warns that a regulator's own per-class licence tally is broader and will not match, preventing a common misinterpretation. Pagination behavior is disclosed through insurersPage, total, and nextOffset, which goes well beyond the readOnly and idempotent annotations.

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 every sentence earns its place: scope and payload, the entity-count caveat, the regulator-tally warning, pagination behavior, and sibling routing. The most important scoping and usage guidance is front-loaded, with no filler or repetition of annotation facts.

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, idempotent tool with a rich output schema, the description covers everything an agent needs: what the response contains, how counts should be interpreted, how to page through large markets, and which sibling to use instead. No critical behavioral or selection context 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 the schema already documents country, limit, offset, and compact in sufficient detail. The description reinforces the offset/nextOffset paging loop, but this is also covered by the schema's limit and offset descriptions. Baseline 3 is appropriate because the description does not need to compensate for missing parameter information.

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 names the exact operation and resource: retrieving one country/market with regulator, currency, counts, verification status, market notes, and licensed insurers. It clearly distinguishes itself from the closest sibling by saying 'Prefer get_country_summary for market facts alone', and the title reinforces the full insurer list scope.

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 explicitly tells the agent when to choose a different tool: 'Prefer get_country_summary for market facts alone.' It also explains how large markets paginate, so the agent knows this tool still returns the complete insurer list when handled correctly. This is direct, actionable guidance rather than implied context.

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?