The Cracks Index
Server Details
Read-only MCP server for The Cracks Index: ranks countries and regions on social-safety strength
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 13 of 13 tools scored. Lowest: 3.6/5.
Each tool targets a distinct query: rankings, country details, region details, comparisons, trends, correlations, methodology, and improvement guidance. Despite minor overlaps (e.g., country_fix and improvement_guidance), descriptions clearly differentiate them, so an agent can reliably select the correct tool.
Tool names mix patterns: some start with verbs (compare_countries, get_cracks_index), others with nouns (area_statistics, country_detail, methodology). While readable and clear, the lack of a consistent verb_noun or noun_verb paradigm reduces predictability for an agent.
With 13 tools covering the full spectrum of index queries—rankings, details, comparisons, trends, correlations, methodology, and improvement guidance—the count is well-scoped for the domain. No tool feels superfluous, and the set is neither too sparse nor too bloated.
The tool surface provides complete CRUD-like coverage for the Cracks Index: full ranking, per-area detail and breakdown, comparisons, trends, top movers, indicator correlations, ranking by indicator, methodology, and improvement guidance. No obvious gaps exist for common agent workflows.
Available Tools
15 toolsarea_statisticsWhere an area sits statisticallyARead-onlyIdempotentInspect
Return where one area sits statistically within its own level.
Places an area against its peer group (all areas at the same level in
the latest snapshot): its percentile, the distance from its composite
score to the level median, best and worst, and the handful of areas
nearest to it by score. Useful for answering "is this area typical, or
an outlier?".
Read-only, area-level aggregates only, no personal data.| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | An ISO-3166 alpha-3 country code (e.g. 'NLD') or an area code of an EU NUTS-2 region or Dutch municipality (e.g. 'NL32', 'GM0363'). Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms read-only behavior ('Read-only, area-level aggregates only, no personal data'), adding value beyond annotations which already declare readOnlyHint=true. It also discloses the type of output (percentile, distance, etc.), enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core action, and each sentence adds value. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers purpose, usage context, and safety without needing to repeat return field details. It is complete for an AI to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage describing the 'area' parameter with examples and case-insensitivity. The description adds no additional parameter-specific meaning, meeting the baseline for well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns statistical placement of an area within its own level, using specific verb and resource. It distinguishes from siblings like 'country_detail' or 'compare_countries' by focusing on peer-group statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context by stating it's useful for answering outlier questions ('is this area typical, or an outlier?'). It implies when to use but does not explicitly name alternatives or when not to use it, leaving slight room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_countriesCompare countriesARead-onlyIdempotentInspect
Compare the composite score and rank of several countries.
``iso3_list`` is a list of ISO-3166 alpha-3 country codes.| Name | Required | Description | Default |
|---|---|---|---|
| iso3_list | Yes | List of ISO-3166 alpha-3 country codes to compare side by side, e.g. ['NLD', 'DEU', 'FRA']. Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds no further behavioral context. It does not disclose what happens with invalid ISO codes, data source, or any limitations beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: one sentence for purpose and one line for the parameter. It front-loads the core action without any filler, making it easy for an AI to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated in context), the description adequately covers purpose and parameter. However, it could be slightly improved by noting that the composite score is from the same index used by sibling tools like get_cracks_index, providing a hint for cross-tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the parameter with full description (100% coverage), including details like case-insensitivity and example. The tool description merely repeats the schema's parameter description, adding no new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compare the composite score and rank of several countries,' specifying the verb 'compare' and the resource 'composite score and rank of several countries.' This distinguishes it from sibling tools like country_detail or get_regions, which handle single countries or regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when wanting side-by-side comparison of multiple countries) but does not explicitly differentiate from alternatives like indicator_ranking or area_statistics. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_gemeentenCompare Dutch municipalities on the social domainARead-onlyIdempotentInspect
Compare the social-domain profile of several Dutch municipalities.
Given two to six CBS GM-codes, returns a side-by-side comparison of their
four v1 social-domain indicators plus composite score and rank. Useful
for an agent answering "how does municipality A compare to B on the
social domain".
Read-only, no personal data. wmo_pressure and youth_care_load are context
only — shown but never scored. CBS aggregates describe an area, not its
quality. Netherlands-only.| Name | Required | Description | Default |
|---|---|---|---|
| region_codes | Yes | Two to six CBS GM-codes of Dutch municipalities, comma-separated, e.g. 'GM0363,GM0599,GM0518'. Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, not destructive. Description adds 'Read-only, no personal data' and important context: 'CBS aggregates describe an area, not its quality'. Also clarifies which indicators are not scored. Fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise multi-sentence description. Each sentence adds value: purpose, input/output, usage example, caveats. No redundant or missing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations cover safety, description fully covers usage context, limitations (Netherlands-only, context-only indicators), and behavioral traits. Complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with 100% schema coverage. Description does not add extra semantics beyond the schema (which already explains format and case-insensitivity). According to calibration, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it compares social-domain profiles of Dutch municipalities using CBS GM-codes. Specifies input range (2-6), output (side-by-side comparison of four indicators, composite score, rank), and scope (Netherlands-only). Distinguishes from siblings like compare_countries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case: 'how does municipality A compare to B on the social domain'. Implicitly excludes non-municipal or non-Dutch use cases. Mentions context-only indicators. Lacks explicit 'when not to use', but sibling tools cover other domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_detailCountry detailARead-onlyIdempotentInspect
Return one country's score, rank and per-indicator breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| iso3 | Yes | ISO-3166 alpha-3 country code, e.g. 'NLD' for the Netherlands. Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the output fields (score, rank, per-indicator breakdown), providing context beyond the annotation's safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose. No unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, read-only, existence of output schema), the description is fully complete. It covers what the tool returns and its scope without needing further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the 'iso3' parameter, including format, example, and case-insensitivity. The description does not add any additional parameter information, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning one country's score, rank, and per-indicator breakdown. It uses a specific verb ('return') and resource ('one country's data'), distinguishing it from siblings like 'compare_countries' and 'indicator_ranking'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details of a single country, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or comparisons to siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
country_fixCountry: highest-impact fixARead-onlyIdempotentInspect
Return the single highest-impact improvement for one country.
The Cracks Index names, alongside each country's score, the one change most associated with the fastest improvement, turning a ranking into a constructive, actionable signal. Read-only, no personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| iso3 | Yes | ISO-3166 alpha-3 country code, e.g. 'NLD' for the Netherlands. Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces with 'Read-only, no personal data' and adds context about the Cracks Index, providing sufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, no wasted words. The key purpose is front-loaded, and the second paragraph adds necessary context without superfluous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read-only tool with an output schema, the description explains the concept and return value adequately. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described iso3 parameter. The description does not add further detail about the parameter, hence baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'the single highest-impact improvement for one country', with a specific verb and resource. It is distinct from siblings like compare_countries or get_cracks_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the context of the Cracks Index and when to use (to get actionable improvement). It lacks explicit alternatives or when-not-to-use, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gemeente_social_profileDutch municipality: social-domain profileARead-onlyIdempotentInspect
Return the Dutch social-domain profile for one municipality.
Given a CBS GM-code, returns that municipality's four v1 social-domain
indicators — social-assistance receipt, modelled homelessness, Wmo use
and youth-care use — each with its raw value, source and whether it was
measured or modelled. The composite score and rank are included for
context, alongside the v0-equivalent score.
Read-only, no personal data. wmo_pressure and youth_care_load are context
only — never folded into the score. CBS aggregates describe an area, not
its quality. Netherlands-only: the deeper municipal layer exists for
Dutch municipalities.| Name | Required | Description | Default |
|---|---|---|---|
| region_code | Yes | CBS GM-code of a Dutch municipality, e.g. 'GM0363' (Amsterdam) or 'GM0599' (Rotterdam). Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context: 'Read-only, no personal data', clarifies that wmo_pressure and youth_care_load are context-only, and cautions that CBS aggregates describe area quality, not the municipality's quality. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized (several sentences) but each sentence adds value: main action, list of indicators, composite score context, behavioral notes, and scope. It's front-loaded with the core purpose. A minor reduction could improve conciseness without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (signaled by 'has output schema: true'), the description doesn't need to list return values. It explains the structure (four indicators, composite score, v0-equivalent) and adds critical usage context that is not in the schema, such as the role of wmo_pressure and youth_care_load. It is complete for a single-municipality profile tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter region_code, which already includes a clear description with examples and case-insensitivity. The tool description only restates the input concept ('Given a CBS GM-code') without adding new semantic meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Dutch social-domain profile for one municipality using a CBS GM-code. It lists the four indicators and composite score, and the 'Netherlands-only' and 'municipal layer' remarks help distinguish it from sibling tools like compare_gemeenten or region_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Return the Dutch social-domain profile for one municipality' and notes the Netherlands-only constraint. While it doesn't directly contrast with siblings, the context signals (single parameter, single municipality focus) imply when to use it. Slightly more explicit alternatives would raise the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cracks_indexCountry rankingARead-onlyIdempotentInspect
Return the full country ranking for the latest published snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, destructiveHint. The description adds context: ranking is 'full' and based on 'latest published snapshot', which implies it may change as snapshots update. Beyond annotations, the description clarifies scope and timing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, immediately front-loaded with the core purpose. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and full annotations, the description sufficiently characterizes what the tool returns (full ranking) and when (latest snapshot). Output schema likely covers return format, so completeness is achieved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, but none is needed. Baseline for 0 parameters is 4, and description does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return', the resource 'full country ranking', and specificity 'for the latest published snapshot'. It distinguishes from sibling tools like indicator_ranking or country_detail by specifying it returns the full ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings like indicator_ranking or compare_countries suggest different use cases, but the description does not clarify why one would choose get_cracks_index over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_regionsList regions and municipalitiesARead-onlyIdempotentInspect
List sub-national areas in the Cracks Index, ranked within their level.
The index covers sub-national areas as well as countries: EU regions
(NUTS-2) and Dutch municipalities. This tool returns those areas with
their composite score and rank.
Parameters
----------
level : optional
Filter by area level: ``nuts2`` (EU regions) or ``gemeente`` (Dutch
municipalities). Omit to return all sub-national areas.
country_iso3 : optional
ISO-3166 alpha-3 country code to restrict the list to one country's
areas (e.g. ``NLD``).
limit : optional
Maximum number of areas to return (1-1000, default 200).
Read-only, no personal data. Ranks are within the area's own level.| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Filter by area level: 'nuts2' for EU NUTS-2 regions or 'municipality' for Dutch municipalities. Omit to include all levels. | |
| limit | No | Maximum number of areas to return (default 200). | |
| country_iso3 | No | Optional ISO-3166 alpha-3 country code to restrict the result to one country's areas, e.g. 'NLD'. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint, idempotentHint, and destructiveHint false. The description adds that it is read-only and contains no personal data, and clarifies that ranks are within the area's own level, providing useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief intro, then a parameter section with clear bullet points. Every sentence adds information, with no wasted words. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 3-parameter tool with full schema coverage and an output schema present (not shown but indicated), the description is complete. It explains the data returned (areas with composite score and rank), the filtering options, and behavioral characteristics (read-only, no personal data). No gaps apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with descriptions for each parameter. The description adds value by explaining the default limit (200) and the range (1-1000), and supplements schema details like 'Omit to return all sub-national areas' for the level parameter. However, the schema itself is already descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sub-national areas (EU NUTS-2 regions and Dutch municipalities) ranked within their level, with composite score and rank. This distinguishes it from sibling tools like region_detail (which likely focuses on a single region) and area_statistics (which may provide aggregated stats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the filtering parameters but does not explicitly state when to use this tool versus alternatives like region_detail or compare_countries. It implies usage by describing the output (list of all areas), but lacks explicit 'when to use' or 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
improvement_guidanceImprovement guidanceARead-onlyIdempotentInspect
Return constructive improvement guidance for one area.
Given an area identifier — an ISO-3166 alpha-3 country code, an EU NUTS-2 region code or a Dutch municipality CBS GM-code — returns that area's highest-impact improvement lever from the Cracks Index, together with Fynqo's approach to earlier, joined-up coordination and a link to the public "claim your score" page where an organisation can request a deeper local report.
Read-only, no personal data. The lever is framed as "the change most associated with improvement". It is general, aggregated guidance, not policy, medical, legal or financial advice, and carries no promise of a guaranteed score gain (sales-engine §3.4, §5).
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | An ISO-3166 alpha-3 country code (e.g. 'NLD') or an area code of an EU NUTS-2 region or Dutch municipality (e.g. 'NL32', 'GM0363'). Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds crucial behavioral context: the lever is 'general, aggregated guidance', not advice, and carries no guarantee of score gain. It also references legal disclaimers and sales-engine terms, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and well-structured. It has multiple sentences, but each adds necessary context. Minor room for tightening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, high schema coverage, and existing annotations, the description fully covers output nature, limitations, and a public link. It is complete for an agent to understand what the tool does and its boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description. The description adds value by noting case-insensitivity and providing examples, but it does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'constructive improvement guidance for one area' given an area identifier. It specifies the types of codes (ISO alpha-3, NUTS-2, Dutch municipality) and what the output contains (highest-impact lever, approach, link). This distinguishes it from sibling tools like area_statistics or indicator_ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when needing improvement guidance for an area) and notes it is read-only with no personal data. However, it does not explicitly list alternative tools or state when not to use, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
indicator_correlationsIndicator correlationsARead-onlyIdempotentInspect
Return pairwise correlations between the six indicators across areas.
Computes the Pearson correlation coefficient between every pair of the six Cracks Index indicators, using each area's direction-corrected normalised score. Adds a short plain-language note naming the strongest relationship. A coefficient near +1 means areas that do well on one indicator tend to do well on the other; near -1 means the opposite.
Read-only, area-level aggregates only, no personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Area level to correlate over: 'country', 'nuts2' (EU regions) or 'gemeente' (Dutch municipalities). Defaults to 'country'. | country |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by explaining coefficient interpretation, area-level aggregates, and no personal data, which enriches understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two well-structured paragraphs: first sentence summarizes purpose, then details method and meaning. No extraneous information, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (correlation computation), schema coverage of one param, annotations covering safety, and presence of output schema, the description explains the purpose, method, and interpretation well. It might omit output format details but output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with a clear description for the single 'level' parameter. The tool description does not add further details about the parameter, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes pairwise Pearson correlations between six indicators across areas, adds a plain-language note, and is read-only. It uses specific verbs and resources, and distinguishes from siblings like 'indicator_ranking' or 'area_statistics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for correlation analysis but does not explicitly exclude alternatives or state when not to use. It is clear but lacks explicit guidance on context versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
indicator_rankingRank areas by one indicatorARead-onlyIdempotentInspect
Rank all areas by a single chosen indicator.
Returns every area's value for one indicator, ordered best-first by the
direction-corrected ``normalized_score`` (a higher normalised score
always means fewer cracks on that indicator). The raw value and unit are
included so the figure can be quoted directly.
Read-only, area-level aggregates only, no personal data.| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Area level to rank: 'country', 'nuts2' (EU regions) or 'gemeente' (Dutch municipalities). Defaults to 'country'. | country |
| limit | No | Maximum number of areas to return (1-500, default 200). | |
| indicator_key | Yes | One of the six Cracks Index indicators: 'problem_debt', 'eviction_rate', 'mh_treatment_gap', 'youth_care_unmet', 'food_insecurity' or 'material_deprivation'. See the 'methodology' tool for definitions. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds that results are ordered best-first by normalized_score, includes raw value and unit for direct quoting, and specifies that only area-level aggregates without personal data are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, front-loaded with the core purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and all parameters are documented in the schema, the description provides sufficient context: ordering direction, inclusion of raw values, read-only nature, and no personal data. It is complete for a ranking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions 'a single chosen indicator' but does not add meaning beyond the schema definitions for level, limit, and indicator_key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rank all areas by a single chosen indicator,' providing a specific verb ('rank') and resource ('areas by indicator'). It distinguishes from sibling tools like compare_countries or country_detail by focusing on ranking a single indicator across all areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ranking areas by one indicator, but lacks explicit guidance on when to use this tool versus alternatives like compare_countries or area_statistics. It does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
methodologyMethodology and sourcesARead-onlyIdempotentInspect
Return the index methodology: indicators, weights, direction, sources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering behavioral traits. The description adds value by specifying the returned content (indicators, weights, etc.), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all necessary information succinctly. Every word is purposeful, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no parameters and an existing output schema, the description fully covers what the tool returns. It is self-contained and sufficiently complete for the agent to understand its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, the description does not need to elaborate on parameters. The absence of parameters is handled appropriately, and no additional semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: returning the index methodology with specific components (indicators, weights, direction, sources). The verb 'return' and the detailed listing make it highly specific and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like indicator_correlations or get_cracks_index. The description only states the action, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
region_detailRegion detailARead-onlyIdempotentInspect
Return one sub-national area: score, rank, indicator breakdown and fix.
Given a region code (an EU NUTS-2 code or a Dutch municipality CBS
GM-code), returns that area's composite score, its rank within its own
level (regions rank against regions, municipalities against
municipalities), the per-indicator breakdown and the single highest-impact
improvement for the area.
Read-only, no personal data.| Name | Required | Description | Default |
|---|---|---|---|
| region_code | Yes | Area code of an EU NUTS-2 region or Dutch municipality, e.g. 'NL32' (Noord-Holland) or 'GM0363' (Amsterdam). Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'Read-only, no personal data,' which confirms and slightly extends annotation context. No additional behavioral traits (e.g., rate limits, auth) are disclosed, so minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the main purpose, and each sentence adds meaningful detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown but known), so return values need not be detailed. The description covers all key output components (score, rank, breakdown, fix) and input requirements, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds marginal value by reiterating code types and case-insensitivity already present in the schema. The baseline is 3, and the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a sub-national area's score, rank, indicator breakdown, and fix. It uses specific verbs and resources, and the mention of 'single highest-impact improvement' differentiates it from siblings like get_regions or compare_countries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains input requirements (region code types) and output contents, implying use for detailed area analysis. However, it does not explicitly state when to use this tool versus alternatives like area_statistics or compare_countries, so guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_trendsScore history over timeARead-onlyIdempotentInspect
Return one area's composite-score history across every snapshot.
Given an area identifier — an ISO-3166 alpha-3 country code, an EU NUTS-2 region code or a Dutch municipality CBS GM-code — walks every published Cracks Index snapshot and returns that area's composite score and rank at each point in time, plus the net change from the first to the most recent snapshot.
Read-only, area-level aggregates only, no personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | An ISO-3166 alpha-3 country code (e.g. 'NLD') or an area code of an EU NUTS-2 region or Dutch municipality (e.g. 'NL32', 'GM0363'). Case-insensitive. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds significant behavioral context: it walks every snapshot, returns composite score, rank, and net change, and states the tool is 'read-only, area-level aggregates only, no personal data.' This expands on the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using bullet points to front-load the core action. Every sentence earns its place, covering identifier types, the iterative process, return contents, and a safety note. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter with complete schema documentation and an output schema (as indicated by context signals), the description fully explains the tool's behavior, constraints, and return structure. It leaves no gaps for an AI agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'area' with a thorough description covering valid formats and case-insensitivity. Schema description coverage is 100%, meeting the high-coverage baseline. The description adds no new parameter-specific details beyond what the schema already provides, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Return') and clearly identifies the resource ('composite-score history over time' for an area). It explicitly lists valid identifier types (ISO-3166 alpha-3, NUTS-2, CBS GM-code), distinguishing this tool from siblings like 'area_statistics' which provide static snapshots or 'indicator_ranking' which provides rankings. The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool accepts area identifiers with explicit code formats and is read-only returning aggregates. It implies usage for historical trend analysis but does not explicitly state when not to use it or name alternative tools for other tasks (e.g., use 'country_detail' for a full profile). The mention of 'no personal data' provides a subtle exclusion cue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_moversBiggest risers and fallersARead-onlyIdempotentInspect
Return the biggest risers and fallers between the two latest snapshots.
Compares every area's composite score in the most recent snapshot
against the snapshot before it and returns the areas that improved most
(``improvers`` — score fell) and worsened most (``decliners`` — score
rose). Needs at least two snapshots; returns an explanatory empty
payload otherwise.
Read-only, area-level aggregates only, no personal data.| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Area level to rank movers within: 'country', 'nuts2' (EU regions) or 'gemeente' (Dutch municipalities). Defaults to 'country'. | country |
| limit | No | How many risers and how many fallers to return each (1-50, default 5). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. Description adds 'read-only, area-level aggregates only, no personal data' and clarifies empty payload condition, providing additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a clear purpose: main function, comparison logic and fallback, and read-only assurance. No wasted words, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple read-only tool with annotated safety hints and an output schema (not shown but present). Covers behavior, preconditions, and data scope adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for both parameters (level and limit). Description adds no further meaning beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'return', resource 'biggest risers and fallers', and context 'between the two latest snapshots'. It clearly distinguishes from sibling tools like area_statistics or compare_countries by focusing on top movers over time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States precondition 'needs at least two snapshots' and fallback behavior 'returns an explanatory empty payload otherwise'. Provides clear when-to-use context but does not explicitly mention when not to use or alternatives beyond the implied distinction from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!