Insurers Global

Get a group’s licensed footprint by country

get_footprint

Read-onlyIdempotent

Licensed footprint: which legal entity of an insurance group is licensed in which country, with collected branches, EEA freedom-of-services passporting and GLEIF parents. Pass exactly one group slug (from list_groups, e.g. "allianz") for the country × entity matrix, or an insurer slug for that entity alone. A large group returns its whole matrix with a first page of entity records; entitiesPage gives the nextOffset to pass as offset. Licence rows come from the directory registers; relationship enrichment comes from GLEIF and EIOPA. Null or empty enrichment means it has not been collected, not that no relationships exist.

Input Schema

TableJSON Schema

Name	Required	Description
`group`	No	Group slug, e.g. "allianz".
`limit`	No	Maximum entity rows to return. Long lists also stop early to keep the response small; the page object reports total and nextOffset. Group footprints only.
`offset`	No	Entity rows to skip, for paging. Group footprints only.
`insurer`	No	Insurer slug, when asking about one entity.

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.

Changed2 schema fields changedSep 23, 2026

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. Group footprints only.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

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

Changed1 schema field changedSep 17, 2026
- changedInput schema / properties / group / description
```
Previous value: -"Group slug, e.g. \"vig\"."New value: +"Group slug, e.g. \"allianz\"."
```
First observedSep 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, and the description adds meaningful behavioral nuances: large groups return a matrix plus a first page, entitiesPage provides nextOffset, enrichment sources are named, and null enrichment means 'not collected' rather than 'no relationships'. This materially improves the agent's interpretation of results.

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 moderately long but every sentence delivers distinct value: definition, parameter constraints, paging, data sources, and null semantics. It is front-loaded with the most important concept and contains no filler.

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 output schema exists, annotations are present, and the schema covers all parameters, the description fills the remaining gaps: response shape for large groups, paging mechanics, data provenance, and the meaning of empty enrichment. Nothing an agent needs to call the tool correctly 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. The description goes beyond the schema by clarifying that group vs insurer changes the scope of the result, that paging applies to group footprints, and that the slug examples come from list_groups. This is useful but not exhaustive, so a 4 is appropriate.

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 precise definition of 'licensed footprint' and ties it to a concrete matrix of legal entity, country, branches, passporting, and GLEIF parents. It clearly distinguishes group-level and insurer-level invocations, and the title's verb 'Get' matches the operation.

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?

It gives explicit usage context by saying to pass exactly one group slug from list_groups or an insurer slug, and explains the difference in what each returns. It does not explicitly name sibling tools as alternatives, but the usage conditions are clear enough for an agent to choose between group and insurer modes.

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?