DaedalMap is a geographic data query engine providing access to global disaster, economic, and demographic datasets via MCP tools, with both free and paid access options.
Discovery (Free)
get_catalog – List all available agent-ready data packs
get_pack – Get detailed metadata, coverage, freshness, and example queries for a specific pack (e.g., earthquakes, volcanoes, currency, hurricanes, un_sdg, world_factbook, worldpop, tsunamis)
Disaster Data
get_live_earthquake_events (Free) – Recent/preliminary earthquake data from USGS FDSN, with filters for time window, magnitude, and ordering
get_earthquake_events (Paid – x402 Base USDC) – Enriched historical earthquake events with stable geographic IDs; exact price returned before any charge
get_volcanic_activity (Free) – Historical volcanic eruption records from the Smithsonian dataset (VEI and other metrics)
get_live_volcano_events (Free) – Recent volcanic eruption updates from Smithsonian/GVP, filterable by recency, VEI, and ongoing status
get_tsunami_events (Paid – x402 Base USDC) – Historical tsunami events; exact price returned before any charge
Economic & Currency Data
get_fx_rates (Free) – Foreign exchange rates at daily, weekly, or monthly granularity
Generic Multi-Pack Access
query_dataset (Free or Paid depending on pack) – Flexible query tool for any pack or source by pack_id or source_id; covers free packs (currency, hurricanes, un_sdg, world_factbook, worldpop) and paid packs (earthquakes, tsunamis)
General Capabilities
Filter by time ranges, geographic region IDs, and comparison clauses
Control result size (up to 500 rows), sorting, and output format
All tools are read-only
Most callers do not need to run anything. DaedalMap is a live remote MCP server and HTTP API for making geographic references interoperable:
MCP endpoint: https://app.daedalmap.com/mcp (streamable HTTP)
Start with help for guided onboarding, then use the free geography tools to
identify reference systems, transform coordinates or boundaries, build
crosswalks, and assign stable loc_id values
Bring your own data, make its geography loc_id compatible, and join it to
other prepared data or DaedalMap's maintained data packs
Download geometry and work locally, call the hosted MCP, or self-host this open runtime
Discover current data packs with get_catalog and current geometry coverage
with read_geometry_catalog; coverage can grow without changing the MCP entry
point or workflow
Some execution lanes are free and licensed commercial lanes challenge through x402 before any charge
Agent docs: https://daedalmap.com/docs/for-agents
The rest of this README is the self-host / local-runtime path.
DaedalMap is a map-first geographic query engine. This repository is the open app/runtime for developers who want to run it locally, self-host it, point it at their own data, or extend it with compatible geographic datasets.
Public surfaces:
App: https://app.daedalmap.com
Website/docs: https://daedalmap.com
There are now two valid ways to approach DaedalMap locally:
GitHub/self-host path
use this repo directly
best for developers, custom data work, and users who want to control setup
Downloadable launcher path
curated wrapper + engine artifact + pack install flow
best for users who want the same runtime with less setup friction
These should stay the same product at the runtime/contract level, but they do not need identical UI on every surface.
If you are using this public GitHub repo as a self-host/local runtime, the practical setup contract right now is:
a local data location (DATA_ROOT, unless you use the default app-data path)
optionally, an LLM API key for the built-in local chat UI
Hosted account wiring and private verifier endpoints are optional for self-host use. Hosted collector scheduling and scheduled-jobs hosts such as the private DigitalOcean nightly box are not part of this public repo.
Related MCP server: STAC MCP Server
Use this repo if you want to:
run the DaedalMap runtime on your own machine or server
point the runtime at local data or a cloud-backed data plane you control
inspect or extend the open runtime behavior
build compatible geographic datasets and pack-style workflows around the engine
Typical use cases:
show earthquakes, floods, wildfires, storms, volcanoes, or tsunamis for a place and time window
compare population, economic, and disaster context in the same workflow
move between local development, self-hosted runtime operation, and hosted-style runtime behavior without changing the basic mental model
DaedalMap itself is built around three ideas:
ask in plain language instead of assembling GIS workflows first
keep the map as the primary interface, not an afterthought
separate runtime delivery from maintained data-pack delivery
This repo is therefore best read as:
the open runtime engine
the self-host/developer entry point
the source of truth for the downloadable engine snapshot users install through the launcher
It is not the hosted account, billing, or admin surface. Those product surfaces are separate from the public runtime and may evolve faster than the downloadable runtime UI.
If you are deciding between this repo and the downloadable launcher, use this rule of thumb:
use the GitHub repo when you want:
code access
self-host setup
custom data or custom pack work
runtime-level experimentation
use the downloadable launcher when you want:
a curated install/update path
a local Research-oriented runtime with less setup work
pack installs and local runtime management without treating Git as the main UX
The goal is that both paths converge on the same core runtime behavior even if their setup UX differs.
If you are browsing this repository, treat it as the developer and self-host entry point.
If you want a more guided local install path, use the downloadable launcher when it is available through release/distribution channels.
In other words:
GitHub checkout = source, self-host, customization, local development
downloadable launcher = curated local install and runtime management
Both paths are intended to lead to the same DaedalMap runtime family.
The hosted runtime ships with 40+ curated sources across disasters, demographics, economics, and climate. Coverage below reflects the current maintained pack inventory.
Source | Scale | Time Range |
USGS Earthquakes | 1M+ events | 2150 BC - present |
IBTrACS Hurricanes/Cyclones | 13K storms | 1842 - present |
NOAA Tsunamis | 2.6K events | 2000 BC - present |
Smithsonian Volcanoes | 11K eruptions | Holocene |
Global Wildfires | 940K events/year | 2002 - 2024 |
USA/CAN Tornadoes | 81K events | 1950 - present |
Global Floods | 4.8K events | 1985 - 2019 |
Global Landslides | 45K events | 1760 - present |
Disaster events include 22M+ geographic location relationships and 566K cross-disaster links (aftershocks, triggered events).
Source | Countries | Years | Category |
Our World in Data CO2 | 217 | 1750 - 2024 | Environment |
WHO Health Statistics | 198 | 2015 - 2024 | Health |
IMF Balance of Payments | 195 | 2005 - 2022 | Economy |
UN Sustainable Development Goals | 200+ | 2000 - 2023 | SDGs 1-17 |
Eurostat Demographics | 37 European countries | 2000 - 2024 | Demographics |
Country | Source Count | Examples |
USA | 15+ | Census, FEMA National Risk Index, NOAA storms |
Canada | 3 | Statistics Canada, NRCan earthquakes, drought |
Australia | 2 | ABS population, BOM cyclones |
Disasters are displayed with animated, type-specific rendering:
Point + radius: earthquakes, volcanoes, tornadoes
Track/trail: hurricanes and cyclones
Radial wave: tsunamis
Polygon fill: wildfires, floods
DaedalMap now treats runtime behavior as a 2-axis matrix:
INSTALL_MODE
local = local app/runtime install
cloud = hosted/server deployment
RUNTIME_MODE
local = query local data
cloud = query managed cloud-backed data via local cache + DuckDB httpfs
Supported combinations:
local install + local data
local install + cloud data
cloud install + cloud data
Not supported as a first-class runtime shape:
cloud install + local data
The current hosted/runtime direction is:
a hosted app runtime
object storage for runtime data
optional auth and account services
In RUNTIME_MODE=cloud, the runtime:
eagerly syncs only small metadata files to local cache
queries parquet directly from object storage via DuckDB httpfs
does not sync the full parquet tree at startup
Hosted deployment topology, release lanes, and operator control-plane details belong in private deployment notes.
That means the same codebase can be used in:
full local-data mode
hosted-style cloud-data mode
Guest users can open the app and try the public workflow without logging in.
Logged-in users currently get:
authenticated session identity
user-scoped frontend persistence
user-scoped backend session cache
account-owned settings and login on daedalmap.com
The public app no longer owns the account/settings UI.
app.daedalmap.com stays focused on the runtime and map engine, while .com
owns login, account, billing, and admin/runtime control-plane views.
cd county-map
pip install -r requirements.txtFor the smallest GitHub/local setup:
Copy-Item .env.example .envThen edit DATA_ROOT. The minimum local configuration is:
DEPLOYMENT=local
INSTALL_MODE=local
RUNTIME_MODE=local
DATA_ROOT=C:/path/to/your/local/dataIf you leave DATA_ROOT blank, DaedalMap uses the default local app-data path and expects your data to live there.
No S3, R2, AWS, database, account, or hosted-control-plane configuration is
needed for this path.
No model API key is required for local data operations. Set
OPENAI_API_KEY or ANTHROPIC_API_KEY only for the built-in local chat UI.
For research using the model from an MCP-capable subscription client, see
docs/RESEARCH_MCP.md.
Hosted-style object-storage configuration is intentionally deployment-specific. For public self-hosting, start with local data. Operators who run a cloud-backed deployment should provide their own object-storage bucket, endpoint, and credentials through environment variables.
Most local users should leave these blank unless they intentionally want overrides:
DATA_ROOT=
APP_URL=
SITE_URL=What they mean:
DATA_ROOT
only used in RUNTIME_MODE=local; leave blank to use the default local app-data folder
APP_URL
optional advertised app URL; leave blank for normal local runs
SITE_URL
optional website/docs/account URL override; leave blank for normal local runs
If you are configuring your own hosted deployment, set:
INSTALL_MODE=cloud
RUNTIME_MODE=cloud
PORT=7000If you want hosted account behavior, connect this runtime to your own auth, database, and analytics stack or to a separate private control plane you operate. Those business-side services are intentionally not bundled here.
python app.pyOpen:
http://localhost:7000
The runtime exposes discovery and query endpoints on your local instance.
Discovery (no auth, no payment):
GET /api/v1/guide
GET /api/v1/catalog
GET /api/v1/packs/{pack_id}
Execution:
POST /api/v1/query/dataset
Self-host instances return commercial_access_unavailable for the paid execution lane unless a commercial verifier is configured. Discovery endpoints work without additional setup.
For managed data access via the hosted API or MCP, see daedalmap.com/docs/for-agents.
The runtime resolves behavior from two explicit modes:
INSTALL_MODE
controls deployment defaults like writable directories and default URLs
RUNTIME_MODE
controls the data plane
Data mode behavior:
RUNTIME_MODE=local
uses DATA_ROOT
RUNTIME_MODE=cloud
uses the hydrated local cloud cache as DATA_ROOT
Default local writable folders on Windows:
CONFIG_DIR=%LOCALAPPDATA%\DaedalMap\config
STATE_DIR=%LOCALAPPDATA%\DaedalMap\state
CACHE_DIR=%LOCALAPPDATA%\DaedalMap\cache
LOG_DIR=%LOCALAPPDATA%\DaedalMap\logs
PACKS_ROOT=%LOCALAPPDATA%\DaedalMap\packs
DATA_ROOT=%LOCALAPPDATA%\DaedalMap\data
In hosted/cloud mode:
metadata is cached locally
parquet is queried remotely from object storage
That makes local cloud-mode testing useful for reproducing hosted-runtime behavior before deploy.
Important note:
the current public repo does not include a bundled data/ demo tree
a source checkout therefore needs either DATA_ROOT in local mode, or RUNTIME_MODE=cloud with cloud storage configured
built-in local chat needs OPENAI_API_KEY or ANTHROPIC_API_KEY; the hosted
Research MCP instead uses the model in the researcher's MCP-capable client
The old “demo data folder plus converters” framing is no longer the whole story.
The current direction is:
the engine stays open
maintained data is packaged as packs
packs are validated and promoted with explicit release gates
runtime catalogs eventually depend on pack availability, installation, and entitlement state
Key concepts:
available packs
installed packs
entitled packs
active runtime catalog
These are intentionally distinct.
Explore chat and Research chat use different discovery paths:
Explore starts from the runtime catalog, then selects sources.
Research starts from the active corpus manifest or loaded artifacts, then selects sources.
After a specific source is selected, they should follow the same source contract:
source-level temporal_coverage is discovery guidance
metric-level metrics.{metric_id}.years is the execution truth
default year windows, slider bounds, and metric year ranges should clamp to the selected metric when available
That shared source-specific logic now lives in mapmover/source_time_contract.py. Use that helper module for metric-aware year bounds instead of re-implementing time-range logic separately in Explore or Research code paths.
/settings now behaves differently depending on mode:
hosted/account-aware mode: redirects to the paired account surface
self-host/local mode: shows local runtime setup guidance
For self-host users, /settings is the in-app reminder page for:
required LLM key setup
current runtime/data/config paths
the current state of local data vs future pack install flow
Important files and folders:
app.py - FastAPI app entrypoint
mapmover/ - runtime logic, routes, path helpers, DuckDB helpers
static/ - frontend app modules and styles
templates/ - app HTML shell
docs/ - local documentation for schemas, runtime notes, and reference material
Public runtime docs live in docs/README.md.
Recommended starting points:
docs/CONTEXT.md - technical router for contributors and researchers
docs/LOCAL_AND_HOSTED.md - runtime mode selection and self-host basics
docs/RUNTIME_MODES.md - Explore, Research, Ops, and Tutorial
docs/RUNTIME_UNIFICATION.md - shared architecture and mode extension contract
docs/DATA_SCHEMAS.md - schema and loc_id conventions
docs/DATA_PREPARATION.md - convert and validate your own data
docs/PACK_AUTHORING.md - build research packs and corpora
Useful local modes:
Full local-data mode
points at your local DATA_ROOT
best current self-host mode for GitHub users
Hosted-style S3 mode
local server, but object-storage-backed data path
best for reproducing hosted runtime behavior before deploy
Installed/runtime-pack mode
planned product direction beyond raw source checkout
engine/runtime installed separately from data packs
pack selection and updates handled outside the repo clone flow
Questions, feedback, or self-host issues: support@daedalmap.com
MIT
If an agent or tool was pointed at this README for programmable access, use:
Agent docs: https://daedalmap.com/docs/for-agents
Machine-readable entry: https://daedalmap.com/llms.txt
Free discovery. Returns the list of live agent-ready data packs available on DaedalMap.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so safety is covered. The description adds that it is 'Free discovery' and returns 'live agent-ready data packs', providing useful 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?
Two sentences with no wasted words. Front-loaded with 'Free discovery' to set context immediately.
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 zero-parameter, read-only tool, the description adequately explains what is returned (list of data packs). No output schema exists, but the return type is implied.
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; schema coverage is 100% vacuously. The description does not need to add parameter info, and baseline for zero parameters is 4.
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 ('Returns'), resource ('list of live agent-ready data packs'), and scope (available on DaedalMap). It distinguishes from sibling tools like get_pack (singular) and event-specific 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 explicit when-to-use or alternative guidance. 'Free discovery' implies a broad overview, but the description does not clarify when to choose this over get_pack or query_dataset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid x402 canonical tool. Queries the published earthquakes_events lane (enriched DaedalMap history with stable loc_id geography). Call without payment first - the server returns HTTP 402 with the exact USDC price before any charge.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Optional caller-supplied request id for tracing and idempotency. | |
| metrics | Yes | Metric ids to return. | |
| filters | Yes | Structured filters including time ranges, region_ids, and compare clauses. | |
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return. | |
| output | No | Optional output controls such as response format hints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond the readOnlyHint annotation: it is a paid tool that requires a preliminary call to get the price via HTTP 402. This adds significant value and includes no contradictions 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 extremely concise with two sentences, no fluff, and front-loads the purpose before the payment note. 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 complexity (6 parameters, 2 required, nested objects) and no output schema, the description covers the payment behavior and data source adequately. However, it does not describe the response format, which is a minor gap for a query 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 coverage is 100%, so the description does not need to add parameter details. The description mentions no additional parameter semantics beyond what the schema provides, resulting in a baseline score of 3.
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 'Queries the published earthquakes_events lane (enriched DaedalMap history with stable loc_id geography)'. The verb 'queries' and specific resource 'earthquakes_events lane' differentiate it from sibling tools like get_live_earthquake_events.
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 guidance on payment procedure ('Call without payment first - the server returns HTTP 402 with the exact USDC price before any charge'), but does not explicitly state when to use this tool versus alternatives (e.g., live vs historical). Usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free tool. Queries the currency pack using filters.region_ids plus filters.time.granularity to return daily, weekly, or monthly FX data.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Optional caller-supplied request id for tracing and idempotency. | |
| metrics | No | Metric ids to return. | |
| filters | Yes | Structured filters including time ranges, region_ids, and compare clauses. | |
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return. | |
| output | No | Optional output controls such as response format hints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds limited behavioral context. It notes the tool is 'free' and mentions daily/weekly/monthly granularity, which is useful but not essential 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?
Extremely concise: one sentence plus 'Free tool.' Front-loaded with that helpful note. Every word earns its place 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?
Given no output schema, the description could explain return format, but for a simple read-only tool it is adequate. It covers key inputs and is sufficient for an agent to understand basic behavior.
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%, so the description adds minimal value beyond the schema. It highlights 'region_ids' and 'time.granularity' from the filters object, but these are already described in the schema properties.
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 uses specific verb 'queries' and resource 'currency pack', clearly identifying the tool's function. It distinguishes from siblings by focusing on FX rates and mentioning key filters like region_ids and time granularity.
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 indicates when to use (for FX data) and mentions key parameters, but does not explicitly exclude use cases or compare with siblings. The sibling tools (e.g., get_catalog, get_earthquake_events) help differentiate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free live wrapper. Calls the USGS FDSN API for recent preliminary earthquake events normalized to DaedalMap event fields. Not the enriched canonical history lane.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Optional caller-supplied request id. | |
| hours | No | Recent lookback window in hours. Ignored when start_time is provided. | |
| start_time | No | Optional inclusive ISO-8601 start datetime. | |
| end_time | No | Optional ISO-8601 end datetime. Defaults to now. | |
| min_magnitude | No | Minimum earthquake magnitude. Defaults to 2.5. | |
| limit | No | Maximum live rows to return. | |
| orderby | No | USGS result ordering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation: it is a free wrapper, calls the USGS API, normalizes fields, and returns preliminary events. No contradictions with annotations. It discloses the tool is for live data and not enriched.
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 extremely concise, consisting of two sentences that are front-loaded with essential information. Every sentence adds value, and there is no unnecessary verbosity.
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?
While the description and schema cover parameters well, there is no output schema or description of the return format. Given the tool's complexity (7 parameters, live data), additional details on the response structure would aid completeness. However, the description is sufficient for basic understanding.
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 input schema already explains all 7 parameters thoroughly. The description does not add additional semantic value beyond what the schema provides, thus 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 it is a free live wrapper for the USGS FDSN API that returns recent preliminary earthquake events normalized to DaedalMap event fields. It distinguishes itself from the enriched canonical history lane, likely referencing sibling tool get_earthquake_events.
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 hints at when to use this tool versus alternatives by stating 'Not the enriched canonical history lane,' implying that for enriched historical data, one should use a different tool. However, it does not explicitly state when to use this tool or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free live wrapper. Calls the Smithsonian/GVP WFS for recent preliminary volcanic eruption updates normalized to DaedalMap event fields. Not the enriched canonical history lane.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Optional caller-supplied request id. | |
| days | No | Recent lookback window in days. Ignored when start_time is provided. | |
| start_time | No | Optional inclusive ISO-8601 start datetime or date. | |
| end_time | No | Optional inclusive ISO-8601 end datetime or date. Defaults to now. | |
| min_vei | No | Optional minimum Volcanic Explosivity Index. | |
| ongoing_only | No | When true, only return eruptions marked continuing by GVP. | |
| limit | No | Maximum live rows to return. | |
| orderby | No | Result ordering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements the readOnlyHint annotation by noting it's a live wrapper from a specific source, indicating non-destructive behavior. No contradictions. It could add details on rate limits or data freshness.
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 sentences, no wasted words, front-loaded with key purpose. Efficient and clear.
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 8 parameters and no output schema, the description covers source and preliminary nature but lacks details on return format, pagination, or behavior of parameters like limit. Adequate but could be more 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?
The input schema has 100% description coverage, so the description does not need to add much. It mentions normalization to DaedalMap event fields but doesn't elaborate on parameter details. 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 it is a live wrapper for recent preliminary volcanic eruption updates from Smithsonian/GVP, normalized to DaedalMap event fields, and explicitly distinguishes from the enriched canonical history lane. This specificity helps differentiate from siblings like get_volcanic_activity.
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 context that this is for recent preliminary updates, not canonical history, implying when to use it. However, it does not explicitly state when not to use it or name alternative tools beyond the implicit contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free discovery. Returns detailed metadata, coverage, freshness, preferred canonical tool guidance, and first-query examples for one pack.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | Pack identifier such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the tool is safe. The description adds the return contents (metadata, coverage, etc.) but doesn't disclose behavioral traits beyond what annotations imply. With annotations present, this is adequate but not exceptional.
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 sentence, which is efficient, but contains jargon ('preferred canonical tool guidance') that reduces clarity. It could be more structured or use plainer language.
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 parameter and no output schema, the description adequately explains what is returned (metadata, coverage, etc.). It is complete for the tool's simplicity, though lacking details on return format.
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%: the pack_id parameter is well-described with examples. The description does not add meaning beyond the schema, meeting the baseline for high coverage.
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 detailed metadata, coverage, freshness, guidance, and examples for one pack. It distinguishes from sibling 'get_catalog' which likely lists packs. However, 'preferred canonical tool guidance' is somewhat vague, preventing a 5.
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 explicit guidance on when to use this tool versus alternatives. 'Free discovery' hints at cost but is not a usage guideline. Sibling tools like 'get_catalog' or dataset-specific tools exist but no exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid x402 tool. Queries tsunamis_events. Call without payment first - the server returns HTTP 402 with the exact USDC price before any charge.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Optional caller-supplied request id for tracing and idempotency. | |
| metrics | Yes | Metric ids to return. | |
| filters | Yes | Structured filters including time ranges, region_ids, and compare clauses. | |
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return. | |
| output | No | Optional output controls such as response format hints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the paid nature and the two-step call process, adding valuable behavioral context not present in 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?
Two sentences, no wasted words. The critical payment workflow is front-loaded. Could be slightly expanded but remains concise.
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?
Despite no output schema, the description omits return structure, parameter usage examples, and does not leverage the full complexity of 6 parameters. Only the payment flow is addressed.
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%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides.
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 'Queries tsunamis_events,' which is a specific verb and resource. It clearly identifies what the tool does, though it does not differentiate from sibling tools like get_earthquake_events.
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 payment handling guidance ('Call without payment first - the server returns HTTP 402'), but does not specify when to use this tool over alternatives or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free tool. Queries volcanoes_events for eruption records and volcanic activity metrics such as VEI.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Optional caller-supplied request id for tracing and idempotency. | |
| metrics | Yes | Metric ids to return. | |
| filters | Yes | Structured filters including time ranges, region_ids, and compare clauses. | |
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return. | |
| output | No | Optional output controls such as response format hints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds no further behavioral context (e.g., rate limits, authentication, data freshness, or whether results are paginated). The 'free tool' note is minor and does not substantively expand transparency 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 two short sentences, front-loading the main purpose. No filler or redundancy. However, the first sentence 'Free tool' could be integrated elsewhere or omitted, but overall it is concise and to the point.
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 (6 parameters, nested objects, no output schema), the description is notably sparse. It does not explain how to structure filters, what metric IDs are valid, or what the response format looks like. More completeness would be needed for an agent to use it effectively without external context.
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 structured schema already documents all 6 parameters. The description adds minimal value by mentioning 'such as VEI' for the metrics array, but it does not clarify filter structure, sort options, or output controls beyond what the schema provides. 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 it queries a specific resource (volcanoes_events) for eruption records and volcanic metrics like VEI. The verb 'queries' is appropriate, and it distinguishes from sibling tools such as get_live_volcano_events which likely focus on real-time data.
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 explicit guidance on when to use this tool versus siblings like get_live_volcano_events or get_earthquake_events. The description only mentions it's a 'free tool' but does not clarify filtering scope, time ranges, or comparison conditions that would help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generic structured query for direct source_id or pack_id access. Free packs: currency, hurricanes, un_sdg, world_factbook, worldpop. Paid packs: earthquakes, tsunamis (x402 Base USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | No | Optional caller-supplied request id. | |
| source_id | No | Concrete source id such as 'earthquakes_events', 'volcanoes_events', 'hurricanes_events', or 'un_sdg/01'. | |
| pack_id | No | Pack id such as 'currency', 'earthquakes', 'volcanoes', 'tsunamis', 'hurricanes', 'un_sdg', 'world_factbook', or 'worldpop'. | |
| metrics | No | Metric ids to return. Use event_count for aggregate counts when supported. | |
| filters | No | Structured filters including time, region_ids, and compare clauses. | |
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return. | |
| output | No | Optional output controls such as response format hints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds pricing context for paid packs but does not disclose other behavioral traits 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 a concise two sentences, front-loading the purpose and efficiently listing relevant packs without unnecessary 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?
With 8 parameters, nested objects, and no output schema, the description provides adequate context for a generic query tool but could benefit from mentioning response format or pagination behavior.
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 parameter descriptions, so the description adds no additional meaning beyond mentioning free/paid packs. 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 'Generic structured query for direct source_id or pack_id access' and lists free and paid packs, distinguishing it from sibling tools like get_catalog or get_earthquake_events.
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 direct access to source or pack IDs but does not explicitly state when not to use or suggest alternatives like get_earthquake_events for specific data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_catalogget_earthquake_eventsget_fx_ratesget_live_earthquake_eventsget_live_volcano_eventsget_packget_tsunami_eventsget_volcanic_activityquery_datasetMost tools have distinct purposes, but get_earthquake_events and get_live_earthquake_events could be confused despite descriptions clarifying paid vs. free and canonical vs. live. Similarly, get_volcanic_activity and get_live_volcano_events require careful reading.
All tools use 'get_' prefix except 'query_dataset', which breaks the pattern. The names are largely descriptive but the mix of 'get_' and 'query_' creates inconsistency.
9 tools is well-scoped for a data marketplace API, covering discovery, live and canonical data for earthquakes, tsunamis, volcanoes, and FX rates without being overwhelming.
The surface covers main domains but lacks dedicated tools for other packs mentioned (hurricanes, un_sdg, world_factbook, worldpop) which are only accessible via generic query_dataset, leaving notable gaps.
MCP server for Mireye Earth — federal-source-cited geospatial data for any MCP-aware agent.
Free GeoNames MCP: countries, cities, POIs, distance & nearby. Remote HTTP + agent token signup.
Regrid MCP — wraps the Regrid Parcel API v2 (regrid.com)
Remote MCP endpoint for U.S. home forecasts, public benchmark data, and permit or zoning readiness.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xyver/daedal-map'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
