DaedalMap Population Estimates
Server Details
Global population estimates from WorldPop, 2000-2030, at country and sub-national levels.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
- Status
- Unhealthy
- Uptime
- 76.0% over 44 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
- Repository
- xyver/daedal-map
- GitHub Stars
- 2
- Server Listing
- daedal-map
TDQS
Scored across 4 tools
The tools have mostly distinct purposes: catalog discovery, pack inspection, data retrieval, and help. Some overlap exists between get_catalog and get_pack since both expose metadata inventories, but the intended flow (catalog → pack → data) is clear.
All tools follow a consistent get_* pattern with clear noun targets: get_catalog, get_data, get_pack, get_tool_help. The naming is uniform, predictable, and easy to pattern-match.
Four tools is well-scoped for a data-access server with a progressive discovery workflow. Each tool has a distinct role and no tool feels redundant or missing from the core catalog-inspect-retrieve flow.
The core access flow is covered, but the description explicitly references a get_event drill-down and 'focused next-step tools' for geometry families that are not present. Agents following these references will hit dead ends, making the surface incomplete for its stated capabilities.
Available Tools
4 toolsget_catalogGet CatalogARead-onlyIdempotentInspect
Discover data packs or geometry families progressively: lite selection, full metric/query inventory, or a raw catalog download URL. Choose one result and call get_pack next. Current catalog: The same geography tools work worldwide across a cataloged baseline of 252 geographic entities, reaching up to Admin 2. Where additional country releases are available, the same calls automatically return deeper administrative tiers or maintained reference families. Additional detail is currently available for Australia, Brazil, Canada, France, Germany, Mexico, United Kingdom, United States.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Use lite to select a pack, full for expanded metric/query inventories, or download for the complete raw catalog URL. | lite |
| loc_id | No | Optional DaedalMap loc_id for catalog='data'. Combine with time_range to discover packs confirmed for both place and time. For place details without pack filtering, use get_loc_id_info. | |
| catalog | No | Catalog family. The geography facade defaults to geometry; other facades default to data. | data |
| time_range | No | Optional inclusive discovery window for catalog='data'. At least one bound is required. | |
| country_scope | No | Optional ISO3 focus for catalog='geometry' with detail='lite'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| packs | No | |
| detail | No | |
| reason | No | |
| catalog | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| pack_count | No | |
| provenance | No | |
| request_id | No | |
| download_url | No | |
| generated_at | No | |
| clarification | No | |
| tool_families | No | |
| catalog_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds genuine behavioral context: progressive discovery levels, a worldwide baseline of 252 geographic entities, Admin 2 coverage, and conditional deeper tiers for selected countries. This is non-redundant and useful.
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 core functionality and next step are front-loaded in the first two sentences, followed by a coverage paragraph that adds useful context. The coverage paragraph is somewhat long but informative rather than padded, so the overall structure remains efficient.
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 zero required parameters, 100% schema coverage, a present output schema, and strong annotations, the description covers the essential call flow and output behavior. The catalog-coverage details help set expectations. Minor guidance about edge cases is unnecessary here, so the definition is sufficiently complete.
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%, and the schema already documents each parameter's meaning, enums, defaults, and constraints. The description only restates the high-level lite/full/download distinction and does not add meaningful parameter syntax beyond the schema. 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 states a specific verb ('Discover') and a specific resource ('data packs or geometry families'), then defines the three output levels (lite, full, download). It also names the immediate next step ('call get_pack next'), which clearly separates this discovery tool from the sibling tools that consume its results.
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 gives a clear sequential usage pattern: discover progressively, choose one result, then call get_pack. It also provides useful context about geographic coverage and deeper administrative tiers. However, it does not explicitly state when to prefer siblings or when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dataGet DataARead-onlyIdempotentInspect
Retrieve rows from one selected published data pack using exact metrics, loc_id-based region filters, time/metric filters, sorting, and a row limit. Disaster event rows include stable event_id values for get_event drill-down. A parent administrative loc_id selects matching descendant rows at the pack's published grain. Call get_pack first; geometry families use their focused next-step tools.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return for the requested source or pack. | |
| output | No | Optional output controls such as response format hints. | |
| filters | Yes | Structured filters including time, region_ids, and compare clauses. | |
| metrics | Yes | Metric ids to return. Use event_count for aggregate counts when supported. | |
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. | |
| request_id | No | Optional caller-supplied request id for tracing and idempotency. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | No | |
| sort | No | |
| error | No | |
| limit | No | |
| reason | No | |
| pack_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| row_count | No | |
| source_id | No | |
| truncated | No | |
| provenance | No | |
| query_mode | No | |
| request_id | No | |
| capability_id | No | |
| clarification | No | |
| filters_applied | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, and the description aligns with these by not suggesting modifications. It adds useful behavior beyond annotations, such as explaining that disaster event rows include stable event_id values and that parent loc_id selects descendant rows, which are non-obvious behaviors. No contradiction with 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 (two sentences) and front-loads the core query capabilities before mentioning drill-down specifics. It is well-structured and every sentence adds meaningful information, but it could be slightly more structured with bullet points for clarity, though not 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 the tool's complexity (7 parameters, nested objects, output schema), the description covers the main usage pattern but omits details like the output schema structure, which is available separately. It provides enough context for correct invocation, though it could mention the need for the pack_id to come from get_catalog as mentioned in the schema.
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 provides 100% coverage with detailed descriptions for all parameters, but the description adds semantic context beyond the schema, such as clarifying that metrics use event_count for aggregate counts and that loc_id filters work hierarchically. This goes beyond the schema's basic parameter descriptions.
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 retrieves rows from a single published data pack with specific filtering, sorting, and limit capabilities. It distinguishes itself from siblings by mentioning the need to call get_pack first and noting that geometry families have focused next-step tools, which helps differentiate from get_catalog and get_tool_help.
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?
It provides clear context on when to use this tool, such as requiring get_pack to be called first and indicating that geometry families should use other tools. However, it does not explicitly state when not to use this tool or directly name alternative tools for geometry cases, so it's slightly below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packGet PackARead-onlyIdempotentInspect
Inspect one selected data pack or geometry family progressively: lite starter contract, full MCP query metadata, or a raw metadata download URL. Use its next_step to retrieve data or call the preferred geometry tool.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file. | lite |
| catalog | No | Metadata family. When omitted, geometry facades default to geometry and known geometry-family ids are inferred; all other calls default to data. | |
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. | |
| release_unit | No | Optional non-country geometry release unit such as GLOBAL or MARINE. Do not combine with country_scope. | |
| country_scope | No | Optional ISO3 country for a geometry family. Omit it to learn which countries publish the family; provide it for country-specific versions, vintages, levels, and artifacts. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| detail | No | |
| reason | No | |
| catalog | No | |
| pack_id | No | |
| sources | No | |
| guidance | No | |
| warnings | No | |
| full_call | No | |
| next_step | No | |
| provenance | No | |
| request_id | No | |
| download_url | No | |
| clarification | No | |
| download_call | No | |
| material_policy | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those hints: the progressive lite/full/download contract and the presence of a next_step handoff for further action.
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 compact and front-loaded with the core purpose, followed by the handoff behavior. Some jargon like 'starter contract' and 'preferred geometry tool' is vague, but the overall structure is efficient.
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?
Rich schema descriptions, an output schema, and safety annotations cover most operational details. The description still leaves the sibling relationship slightly implicit: it would be stronger if it explicitly named get_data or get_catalog and positioned get_pack in the workflow.
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 pack_id, detail, catalog, release_unit, and country_scope are already well documented. The description restates the detail modes ('lite starter contract, full MCP query metadata, raw metadata download URL') but adds no new parameter-level 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 names a concrete verb+resource ('inspect one selected data pack or geometry family') and enumerates the three detail modes: lite, full, and download. 'Inspect' plus the reference to next_step separates it from catalog listing and direct data retrieval 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?
The description implies a workflow: inspect a selected pack, then use next_step to retrieve data or call the preferred geometry tool. It never explicitly names get_catalog or get_data as alternatives, nor states when not to use this tool, leaving sibling routing implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tool_helpGet Tool HelpARead-onlyIdempotentInspect
Describe one tool visible on this facade, including its exact contract, or return a bounded workflow overview for one supported topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Workflow overview. Do not combine with tool_name. | |
| question | No | Optional question used only with a topic overview. | |
| tool_name | No | Exact tool name from tools/list. Do not combine with topic. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| title | No | |
| access | No | |
| reason | No | |
| purpose | No | |
| examples | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| tool_name | No | |
| provenance | No | |
| request_id | No | |
| input_schema | No | |
| clarification | No | |
| recommended_next_calls | No | |
| important_output_fields | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds a bit of behavioral context by mentioning 'exact contract' and 'bounded workflow overview', but it does not disclose potential error conditions or response formats. This is acceptable given the annotations, so a 3 is appropriate.
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, well-structured sentence that efficiently presents both modes without redundancy. Every phrase adds value, and it is front-loaded with the primary 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?
The description is adequate but relies heavily on the schema for constraints (e.g., oneOf logic, enum values, mutual exclusivity). It does not mention optional parameters or edge cases, but given the rich schema and annotations, it covers the essential purpose. A 3 reflects that it is sufficient but not exhaustive.
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% and each parameter already has a thorough description (e.g., 'Do not combine with tool_name'). The tool description adds no extra parameter detail beyond the schema, so the baseline 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?
The description clearly states the tool's purpose: describe a tool (with its exact contract) or return a workflow overview for a supported topic. It uses specific verbs and resources, and the two modes are distinct. This differentiates it from sibling data-fetching tools like get_data and get_catalog.
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 each mode by stating the two options, and the schema enforces mutual exclusivity. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., for actual data retrieval). Still, the purpose is clear enough for an agent to infer correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
get_catalog2 fields changed- added
Input schema / properties / loc_idAdded value: +{ + "description": "Optional DaedalMap loc_id for catalog='data'. Combine with time_range to discover packs confirmed for both place and time. For place details without pack filtering, use get_loc_id_info.", + "type": "string" +} - added
Input schema / properties / time_rangeAdded value: +{ + "additionalProperties": false, + "description": "Optional inclusive discovery window for catalog='data'. At least one bound is required.", + "properties": { + "end": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "start": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + } + }, + "type": "object" +}
5 tool updates
- Changed
get_catalog9 fields changed- added
Input schema / properties / catalogAdded value: +{ + "default": "data", + "description": "Catalog family. The geography facade defaults to geometry; other facades default to data.", + "enum": [ + "data", + "geometry" + ], + "type": "string" +} - added
Input schema / properties / country_scopeAdded value: +{ + "description": "Optional ISO3 focus for catalog='geometry' with detail='lite'.", + "type": "string" +} - added
Input schema / properties / detailAdded value: +{ + "default": "lite", + "description": "Use lite to select a pack, full for expanded metric/query inventories, or download for the complete raw catalog URL.", + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" +} - changed
Output schema / anyOfPrevious value: -[ - { - "required": [ - "packs" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "required": [ + "catalog", + "detail" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / catalogAdded value: +{ + "enum": [ + "data", + "geometry" + ], + "type": "string" +} - added
Output schema / properties / detailAdded value: +{ + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" +} - added
Output schema / properties / download_urlAdded value: +{ + "type": "string" +} - added
Output schema / properties / next_step / anyOfAdded value: +[ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } +] - removed
Output schema / properties / next_step / requiredRemoved value: -[ - "action" -]
- Added
get_data - Changed
get_pack13 fields changed- added
Input schema / properties / catalogAdded value: +{ + "description": "Metadata family. When omitted, geometry facades default to geometry and known geometry-family ids are inferred; all other calls default to data.", + "enum": [ + "data", + "geometry" + ], + "type": "string" +} - added
Input schema / properties / country_scopeAdded value: +{ + "description": "Optional ISO3 country for a geometry family. Omit it to learn which countries publish the family; provide it for country-specific versions, vintages, levels, and artifacts.", + "pattern": "^[A-Za-z]{3}$", + "type": "string" +} - changed
Input schema / properties / detail / descriptionPrevious value: -"Use lite for normal discovery. Use full only for one selected pack when its complete public metadata is required."New value: +"Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file." - changed
Input schema / properties / detail / enumPrevious value: -[ - "lite", - "full" -]New value: +[ + "lite", + "full", + "download" +] - added
Input schema / properties / release_unitAdded value: +{ + "description": "Optional non-country geometry release unit such as GLOBAL or MARINE. Do not combine with country_scope.", + "pattern": "^[A-Za-z0-9_-]+$", + "type": "string" +} - changed
Output schema / anyOfPrevious value: -[ - { - "required": [ - "pack_id" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "required": [ + "catalog", + "pack_id", + "detail" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / catalogAdded value: +{ + "enum": [ + "data", + "geometry" + ], + "type": "string" +} - added
Output schema / properties / detailAdded value: +{ + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" +} - added
Output schema / properties / download_callAdded value: +{ + "type": "object" +} - added
Output schema / properties / download_urlAdded value: +{ + "type": "string" +} - added
Output schema / properties / full_callAdded value: +{ + "type": "object" +} - added
Output schema / properties / next_step / anyOfAdded value: +[ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } +] - removed
Output schema / properties / next_step / requiredRemoved value: -[ - "action" -]
- Changed
get_tool_help7 fields changed- added
Input schema / oneOfAdded value: +[ + { + "not": { + "required": [ + "topic" + ] + }, + "required": [ + "tool_name" + ] + }, + { + "not": { + "required": [ + "tool_name" + ] + }, + "required": [ + "topic" + ] + } +] - added
Input schema / properties / questionAdded value: +{ + "description": "Optional question used only with a topic overview.", + "type": "string" +} - changed
Input schema / properties / tool_name / descriptionPrevious value: -"Exact tool name from tools/list."New value: +"Exact tool name from tools/list. Do not combine with topic." - added
Input schema / properties / topicAdded value: +{ + "description": "Workflow overview. Do not combine with tool_name.", + "enum": [ + "overview", + "data", + "disasters", + "custom_data", + "geometry" + ], + "type": "string" +} - removed
Input schema / requiredRemoved value: -[ - "tool_name" -] - added
Output schema / properties / next_step / anyOfAdded value: +[ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } +] - removed
Output schema / properties / next_step / requiredRemoved value: -[ - "action" -]
- Removed
query_dataset
1 tool update
- Changed
get_pack1 field changed- added
Input schema / properties / detailAdded value: +{ + "default": "lite", + "description": "Use lite for normal discovery. Use full only for one selected pack when its complete public metadata is required.", + "enum": [ + "lite", + "full" + ], + "type": "string" +}
4 tool updates
- Changed
get_catalog1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "packs" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "catalog_version": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "generated_at": { + "type": [ + "string", + "null" + ] + }, + "guidance": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_count": { + "minimum": 0, + "type": "integer" + }, + "packs": { + "items": { + "type": "object" + }, + "type": "array" + }, + "provenance": { + "type": "object" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "tool_families": { + "items": { + "type": "object" + }, + "type": "array" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_pack1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "pack_id" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "guidance": { + "type": "object" + }, + "material_policy": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "sources": { + "items": { + "type": "object" + }, + "type": "array" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_tool_help1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "tool_name" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "access": { + "type": "object" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "examples": { + "type": "array" + }, + "guidance": { + "type": "object" + }, + "important_output_fields": { + "type": "array" + }, + "input_schema": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "provenance": { + "type": "object" + }, + "purpose": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "recommended_next_calls": { + "type": "array" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "tool_name": { + "type": "string" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
query_dataset1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "source_id", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "capability_id": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "filters_applied": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "limit": { + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "query_mode": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "rows": { + "items": { + "type": "object" + }, + "type": "array" + }, + "sort": { + "type": "array" + }, + "source_id": { + "type": "string" + }, + "truncated": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
2 tool updates
- Changed
get_pack1 field changed- changed
Input schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."New value: +"Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change."
- Changed
query_dataset1 field changed- changed
Input schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."New value: +"Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change."
1 tool update
- Added
get_tool_help
2 tool updates
- Changed
get_pack1 field changed- changed
Input schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'."New value: +"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."
- Changed
query_dataset1 field changed- changed
Input schema / properties / pack_id / descriptionPrevious value: -"Pack id such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'."New value: +"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."
3 tool updates
- First observed
get_catalog - First observed
get_pack - First observed
query_dataset
Related MCP Connectors
WorldPop 100 m gridded population estimates from the University of Southampton — total population…
GLOBOCAN — the IARC/WHO Global Cancer Observatory.
Global flood events and extent 1985-present from the Dartmouth Flood Observatory and GFD.
Query UN population data: fertility, mortality, migration, life expectancy for 298 countries.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables population estimates for any supplied polygon from WorldPop 100m gridded data, for years 2000 to 2020, including age and sex structures.230 npmMIT
- FlicenseNot gradedqualityDmaintenanceMCP server for querying the CONAPESCA historical fishing landings database (2001–2026) from Mexico's Pacific and Gulf coasts, providing tools to extract and analyze standardized landing records (avisos de arribo).-
- FlicenseNot gradedqualityBmaintenanceEnables querying demographic, spending, and market data for every place in Europe, offering tools to analyze markets, describe areas, reach audiences, compare and rank places, sample personas, resolve locations, and run structured population queries—all as privacy-protected aggregates.-
- AlicenseNot gradedqualityBmaintenanceProvides access to official U.S. Census Bureau data, including decennial census, American Community Survey, economic census, population estimates, and housing characteristics, across geographic levels from nation to block group. Enables natural-language queries and direct tool calls for demographic and housing analysis.142 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.