daedal-map
DaedalMap MCP server lets you discover, query, and connect geographic data and boundaries via its loc_id identity model, crosswalks, and maintained data packs.
Discover available data packs and geometry families with
get_catalogandget_pack.Learn exact tool contracts and workflows via
get_tool_help.Resolve WGS84 coordinates to administrative
loc_idchains (Admin 0–3) withresolve_point.Resolve deeper points (Admin 4–6 or specific families like postal, watershed, marine) with
resolve_deep_point.Inspect known
loc_ididentities, hierarchy, lifecycle, references, and available packs/geometry withget_loc_id_info.Identify which dataset columns represent geography (
identify_dataset_geography) or verify a code column’s reference system (identify_reference_system).Convert geographic references between systems through
loc_idwithconvert_reference.Compare two geographic identities for containment, common ancestry, and temporal validity with
compare_geographies.Retrieve boundary shapes/GeoJSON for known
loc_ids or administrative scopes withget_geometry.Query maintained data packs with metrics, filters, regions, time ranges, sorting, and limits via
get_data.Drill into disaster events and optionally fetch relationships, affected places, observations, or geometry with
get_event.Use free discovery and small lookups; larger point/reference batches and some data packs are metered with price shown before charge.
DaedalMap
Bring your data. Connect its geography.
DaedalMap is geographic interoperability infrastructure: a loc_id identity
model, versioned boundary geometry, published crosswalks between geography
systems, and maintained data packs. Resolve coordinates and reference codes to
administrative matches, pull compatible shapes and data, and follow crosswalks
into other systems such as census tracts, postal areas, watersheds, and
electoral districts.
Use it through a remote MCP server, an HTTP API, a map app, downloadable files, or this repository, which is the open runtime behind all of them.
Website | App | Agent docs | Geometry | Data packs | Downloads | Convert a file | llms.txt
Connect an agent
The hosted MCP server needs no install or account for discovery:
https://app.daedalmap.com/mcpClaude Code:
claude mcp add --transport http daedalmap https://app.daedalmap.com/mcpCodex:
codex mcp add daedalmap --url https://app.daedalmap.com/mcpAny client that supports streamable HTTP MCP can use the same URL. Start with
get_tool_help with topic='geometry' for geography jobs, or get_catalog, then get_pack,
then get_data for data. Setup for other clients is in the
agent docs.
Discovery and small geography lookups are free. Larger point/reference batches
and some data packs are metered: a paid call returns its exact price before any
charge and is paid from account credit with an API key. get_catalog reports
the access lane for each pack.
Related MCP server: STAC MCP Server
Tools
Job | Tools |
Learn the model |
|
Find what exists |
|
Query maintained data |
|
Inspect one disaster event |
|
Coordinates to places |
|
Identify a column of codes |
|
Translate codes between systems |
|
Inspect and relate places |
|
Retrieve shapes |
|
Each tool takes strict JSON arguments. The calling model turns a user's question into those arguments, and the server returns typed errors with recovery guidance when a call is malformed.
This table is the complete public roster, not a roadmap. Bulk export/job
builders and direct upstream live-feed wrappers remain internal or paused and
are intentionally absent from tools/list.
The loc_id model
loc_id is DaedalMap's geographic identity model. The administrative spine is
the main hierarchy and default join path:
USA country
USA-CA state
USA-CA-037 county
USA-CA-037-221710 census tractOther geography families, such as postal areas, watersheds, tribal areas, and
marine regions, keep their own loc_id identities. Published crosswalks connect
them to the spine and to each other, and each crosswalk row carries its
relationship type, overlap weight, source, and vintage. A direct join works when
both datasets declare the same identity; otherwise the connection runs through a
crosswalk.
Schema details are in docs/DATA_SCHEMAS.md.
Coverage
Geometry: global baseline plus 8+ deeper countries. The same geography tools work worldwide down to Admin 2. Country releases add deeper administrative tiers and reference families for Australia, Brazil, Canada, France, Germany, Mexico, the United Kingdom, the United States, and more as releases publish.
Data: 20+ maintained data packs covering natural hazards (earthquakes, tsunamis, volcanoes, hurricanes, tornadoes, wildfires, floods, weather alerts), hazard risk and environmental burden, economic and business indicators, currency rates, population, and climate.
The catalogs are the authority for what is available now:
Data packs: app.daedalmap.com/api/v1/catalog
Downloads
The Downloads page has three kinds of file:
Program - the map app or local MCP runtime, to run DaedalMap on your machine.
Data pack - maintained records for a subject, with source and release evidence.
Geometry package - boundaries and reference geography for a country or family.
Run it yourself
This repository is the open runtime: the FastAPI server, MCP and HTTP API, and map frontend. Use it to self-host, run against your own data, or extend the engine.
cd county-map
pip install -r requirements.txt
Copy-Item .env.example .envSet a data folder in .env:
INSTALL_MODE=local
RUNTIME_MODE=local
DATA_ROOT=C:/path/to/your/dataLeave DATA_ROOT blank to use the default app-data folder. No cloud storage,
database, or account is needed. The repository does not ship a data folder;
docs/DATA_INSTALLATION.md covers installing packs.
python app.pyThe app opens at http://localhost:7000, and the same MCP server is at
http://localhost:7000/mcp. Discovery routes:
GET /api/v1/guideGET /api/v1/catalogGET /api/v1/packs/{pack_id}POST /api/v1/query/dataset
Model API keys are optional. OPENAI_API_KEY or ANTHROPIC_API_KEY powers the
built-in chat panel only; MCP clients bring their own model. A self-hosted
instance returns commercial_access_unavailable on paid lanes unless you
configure a commercial verifier.
Runtime modes
|
| Use |
|
| Your machine, your data folder |
|
| Your machine, Parquet read from object storage you configure |
|
| A server deployment reading object storage |
In cloud data mode the runtime caches small metadata files locally and queries
Parquet in object storage through DuckDB httpfs. Details are in
docs/LOCAL_AND_HOSTED.md.
Documentation
docs/CONTEXT.md - technical router for the codebase
docs/API_AND_MCP.md - HTTP routes and MCP surfaces
docs/DATA_SCHEMAS.md - schemas and
loc_idconventionsdocs/DATA_PREPARATION.md - convert and validate your own data
docs/DATA_INSTALLATION.md - install data locally
docs/PACK_AUTHORING.md - build research packs and corpora
docs/RESEARCH_MCP.md - research with the hosted MCP
docs/RUNTIME_MODES.md - Explore, Research, Ops, and Tutorial
docs/SECURITY_AND_SELF_HOSTING.md - self-hosting securely
Contact
Questions, feedback, and self-hosting issues: support@daedalmap.com
License
MIT. Data packs and geometry carry their own source licenses, listed in each catalog entry.
Available Tools
13 toolscompare_geographiesCompare Geographic IdentitiesARead-onlyIdempotentInspect
Compare two geographic identities for the public guarantees implemented today: containment/common ancestry and temporal validity for the requested vintages. The response may include additional maintained evidence, but callers must not rely on deeper topology or relationship semantics as a stable contract until that review is complete. Use convert_reference first for names or outside identifiers. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ISO date or year applied to both identities. | |
| items | No | Bounded geography pairs to compare in one call. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| left_as_of | No | Optional ISO date or year for the left identity; overrides as_of. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| left_loc_id | No | First DaedalMap loc_id. | |
| right_as_of | No | Optional ISO date or year for the right identity; overrides as_of. | |
| right_loc_id | No | Second DaedalMap loc_id. | |
| include_successors | No | Include direct successors and present-day descendants for maintained historical identities. Default true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| reason | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| item_count | No | |
| request_id | No | |
| failed_count | No | |
| clarification | No | |
| meter_receipt | No | |
| compared_count | No | |
| spatial_relation | No | |
| temporal_relation | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description warns that the response may include additional maintained evidence and that deeper topology or relationship semantics are not a stable contract. This is valuable non-obvious behavioral context that an agent needs before trusting the output.
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 with no wasted words: the core purpose is front-loaded, the stability caveat is stated, and the prerequisite routing is given. Every sentence earns 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 rich input schema, output schema, and annotations, the description covers the essential behavioral contract, the supported comparison semantics, and the prerequisite conversion step. Nothing critical is missing for an agent to invoke the tool correctly.
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 schema already documents all parameters. The description adds general context like 'requested vintages' and 'names or outside identifiers', but it does not materially deepen parameter-level meaning beyond what the schema 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 names a specific verb ('Compare') and resource ('two geographic identities') and enumerates the exact guarantees covered: containment/common ancestry and temporal validity. It is clearly distinct from the get_* sibling tools and even routes name/identifier resolution to convert_reference.
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 explicitly instructs callers to use convert_reference first for names or outside identifiers, which is a concrete alternative and sequencing rule. It also sets expectations about what callers may rely on, effectively saying when this tool is appropriate and when deeper semantics should not be assumed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_referenceConvert Geographic ReferenceARead-onlyIdempotentInspect
The single geographic reference converter. Converts one reference, or a bounded list, through DaedalMap loc_id: X -> loc_id -> Y. Omit to_system to enter the loc_id universe; provide it for any-to-any conversion. Use get_pack first when the family or country-specific system is unknown. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| iso3 | No | Country hint for crosswalk artifacts. Default USA. | |
| as_of | No | ISO date or year used for time-bounded identities. | |
| items | No | Reference conversions to run in one call. Default public cap is deployment-configurable. | |
| limit | No | Maximum ranked output references to return. Default 10. | |
| value | No | Identifier or name in the input system. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| min_share | No | Optional minimum overlap share threshold. | |
| to_system | No | Optional output reference system. Defaults to DaedalMap loc_id; provide zcta, nws_fire, overlay_nws_public_zone, overlay_tribal, admin_local, or another catalog system for any-to-any conversion. | daedalmap.loc_id |
| request_id | No | Optional caller-supplied request id for tracing. | |
| from_system | No | Input reference system, such as zip, overlay_zcta, nws_fire, tribal, admin_boundary, or loc_id. | |
| country_hint | No | Optional country hint for admin/name resolution. | |
| admin_level_hint | No | Optional admin-level hint for admin/name resolution. | |
| target_admin_level | No | Admin level used as the intermediate crosswalk target. Default admin_2. | |
| relationship_vintage | No | Optional source relationship vintage to require. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| from | No | |
| error | No | |
| loc_id | No | |
| reason | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| to_system | No | |
| item_count | No | |
| request_id | No | |
| from_system | No | |
| clarification | No | |
| meter_receipt | No | |
| converted_count | No | |
| unconverted_count | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, and destructive=false, so the safety profile is covered. The description adds useful context beyond annotations: the loc_id intermediate path, the bounded-list capability, and that no payment is required.
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?
Four short sentences cover what the tool does, how conversion works, the key to_system decision, a routing alternative, and a payment caveat. Every sentence earns its place and the core function is front-loaded.
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 rich output schema, 100% parameter descriptions, and strong annotations, the description provides the missing operational context: the intermediate loc_id step, the get_pack precondition, and the no-payment note. Nothing essential for correct invocation is missing.
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 adds meaningful conceptual semantics by clarifying that conversions route through DaedalMap loc_id and that omitting to_system keeps you in the loc_id universe, which the schema alone does not state as directly.
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 specific verb and resource ('Converts one reference, or a bounded list') and explains the conversion path 'X -> loc_id -> Y'. Calling itself 'The single geographic reference converter' helps distinguish it from sibling tools like get_pack and resolve_point.
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 gives explicit mode guidance: 'Omit to_system to enter the loc_id universe; provide it for any-to-any conversion.' It also names an alternative and its trigger condition: 'Use get_pack first when the family or country-specific system is unknown.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_catalogList Available Packs and Geometry FamiliesARead-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.
| 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by explaining that the tool returns progressively richer selections (lite, full, or download URL) and acts as a precursor to get_pack. No contradiction exists.
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 filler. The first sentence front-loads the tool's purpose and the three output levels; the second sentence provides the immediate next action. Every word earns 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 rich input schema, output schema, and annotations, the description is adequately complete for a discovery tool. It could optionally mention that no parameters are required or clarify conditional defaults (e.g., catalog defaults to data), but these are already structured in the schema, so the minimal gap does not impede correct usage.
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 each parameter already documented. The description adds minor semantic alignment by mapping 'lite selection', 'full metric/query inventory', and 'raw catalog download URL' to the detail enum, but does not go beyond the schema to enrich 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 states a specific verb and resource: 'Discover data packs or geometry families' and elaborates the three progressive detail modes (lite/full/download). It also names the next step 'call get_pack next', which distinguishes this discovery tool from its siblings.
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 tells the agent to choose a result and call get_pack next, establishing the intended flow. Additionally, the loc_id parameter description routes to get_loc_id_info when pack filtering is not needed, providing a clear when-not alternative.
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 | Sort by a sortable field from get_pack; direction defaults to asc. | |
| limit | No | Maximum number of rows to return for the requested source or pack. | |
| output | No | Optional response controls. v1 supports rows only. | |
| filters | Yes | ||
| metrics | Yes | Exact metric ids from get_pack. Use event_count for aggregate counts only when get_pack publishes it. | |
| 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 already signal read-only, idempotent, non-destructive behavior. The description adds value by disclosing stable event_id values for get_event drill-down and that a parent administrative loc_id selects descendant rows at the pack's published grain. These behavioral details go beyond the annotation flags and do not contradict them.
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 four sentences, front-loaded with the core purpose and followed by behavioral routing details. Every sentence contributes information; there is no filler or restatement of the tool name.
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 tool with seven parameters and nested objects, the description plus rich schema and annotations cover prerequisites, sibling routing, regional hierarchy behavior, and the event drill-down path. The output schema exists, so the description does not need to document return values.
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 86%, so parameter semantics are mostly carried by the input schema. The description's phrases such as 'exact metrics' and 'loc_id-based region filters' reinforce, but do not materially extend, the schema descriptions for metrics, filters, and region_ids.
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 opens with a specific action and resource: 'Retrieve rows from one selected published data pack' and enumerates the filtering, sorting, and limiting semantics. It also distances itself from siblings by saying 'Call get_pack first' and pointing geometry families to focused tools, so an agent can tell get_data apart from get_catalog, get_pack, and get_event without opening the schema.
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 prerequisite ('Call get_pack first') and an explicit exclusion ('geometry families use their focused next-step tools'). It also describes the get_event drill-down path. It does not enumerate every sibling-selection condition, such as when to use get_catalog versus get_pack, so it stops short of full coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventGet EventARead-onlyIdempotentInspect
Retrieve one exact disaster event and explicitly requested relationships, affected places, native observations, or geometry. Use get_data to obtain the stable event_id first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Per-section ceiling for relationships, affected places, observations, or geometry frames. | |
| include | No | Optional companion layers. Omit for the lightweight event summary. Geometry is never returned implicitly. | |
| pack_id | No | Optional disaster pack hint. Recommended when known to avoid probing unrelated event sources. | |
| event_id | Yes | Exact stable event_id returned by a disaster-pack get_data row. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| geometry_mode | No | current returns the representative/current shape; timeline returns bounded progression frames where supported. | current |
| relationship_depth | No | Bounded cross-hazard traversal depth when relationships is included. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| event | No | |
| reason | No | |
| pack_id | No | |
| event_id | No | |
| geometry | No | |
| guidance | No | |
| included | No | |
| warnings | No | |
| available | No | |
| next_step | No | |
| source_id | No | |
| event_type | No | |
| next_steps | No | |
| provenance | No | |
| request_id | No | |
| observations | No | |
| schema_class | No | |
| clarification | No | |
| relationships | No | |
| affected_places | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description's additional burden is lower. The description adds value by emphasizing exact matching, explicitly requested companion layers, and the prerequisite relationship to get_data, which helps set operational expectations beyond the structured hints.
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 focused sentences with no filler. The first sentence front-loads the core purpose, and the second provides the essential operational prerequisite. Every word contributes to selection or invocation.
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 complete input schema, output schema, and safety annotations, the description supplies the one critical missing operational detail: where to obtain a valid event_id. The tool is complex enough that a bit more about default lightweight behavior could help, but the schema already covers include and defaults, so no significant gap remains.
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 documents all parameters, defaults, enums, and constraints. The description does not need to restate these details; it adds modest alignment by mentioning the layer categories, but no substantial parameter semantics 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 states a specific verb ('Retrieve'), a precise resource ('one exact disaster event'), and the optional companion layers. It clearly differentiates from get_data, get_catalog, and get_pack by focusing on single-event retrieval rather than listing or fetching event_id sources.
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 instructs the agent to use get_data first to obtain the stable event_id, which is the key prerequisite for correct invocation. It does not exhaustively state when not to use get_event versus every sibling, but the prerequisite guidance and exact-event framing make the intended use context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_geometryRetrieve Shapes for Known loc_idsARead-onlyIdempotentInspect
Shape availability and bounded coordinate retrieval only: use when you already have exact loc_ids, or one administrative parent_loc_id plus target admin_level. The default fast preflight returns has_shape, shape metadata, centroid, and bounding box; set include_polygon=true only for GeoJSON coordinates. Use get_loc_id_info for hierarchy, identity, catalog coverage, or crosswalk facts; get_geometry does not return those place details. Administrative scope queries stay within the optimized Admin Spine layout, while independent geometry families require exact loc_ids. Historical geometry is returned first and successors are never substituted automatically. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| loc_id | No | DaedalMap loc_id, such as USA-CA-037, USA-Z-00601, USA-NWSFZ-AKZ317, EEZ-USA, or IHO1953-240001002. | |
| loc_ids | No | Exact DaedalMap loc_ids to fetch in one call. Default public cap is deployment-configurable and lower when include_polygon is true. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| include_polygon | No | When true, include the full GeoJSON geometry. Default false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| items | No | |
| scope | No | |
| reason | No | |
| missing | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| available | No | |
| next_step | No | |
| requested | No | |
| selection | No | |
| request_id | No | |
| clarification | No | |
| meter_receipt | No | |
| include_polygon | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive, and the description adds meaningful context beyond them: the default fast preflight returns has_shape, shape metadata, centroid, and bounding box, while include_polygon=true is needed only for GeoJSON coordinates. It also discloses that historical geometry is returned first and successors are never substituted automatically, plus 'No payment required.' There is 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 dense but purposeful, with the core purpose and usage guidance front-loaded before the return behavior and sibling routing. Every sentence contributes useful information, though a small amount of redundancy exists between the opening 'exact loc_ids or parent+admin_level' condition and the later Admin Spine versus exact loc_ids distinction. It is appropriately sized for a tool with this much routing nuance.
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 — three mutually exclusive input modes, a nested scope object, an optional polygon flag, and an output schema — the description covers what an agent needs to invoke it correctly. It explains default behavior, the polygon flag's purpose, sibling boundaries, and the no-payment requirement. The output schema handles return-value details, so no major information gap remains.
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 high (83%), so the schema already documents parameters like loc_id, loc_ids, scope, and include_polygon. The description adds useful meaning by clarifying the default response when include_polygon is false and by mapping user intent (exact loc_ids vs. admin parent+level) to the relevant input modes. This goes beyond the schema's basic parameter descriptions without being redundant.
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 opens with a specific verb and resource: it retrieves shape availability and bounded coordinates for known loc_ids or an admin scope. It explicitly distinguishes itself from get_loc_id_info, which covers hierarchy, identity, catalog coverage, and crosswalk facts. The title and description align, leaving no ambiguity about what the tool does.
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 states exactly when to use the tool: when you already have exact loc_ids, or one administrative parent_loc_id plus target admin_level. It explicitly names the alternative, get_loc_id_info, for hierarchy and identity needs, and clarifies that get_geometry does not return those place details. It also notes that administrative scope queries use the Admin Spine layout while independent geometry families require exact loc_ids, giving the agent strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_loc_id_infoInspect Known loc_id IdentitiesARead-onlyIdempotentInspect
Known-place navigation and enrichment tool: use only when you already have one canonical loc_id or a bounded loc_ids array. It returns identity, strict stored parentage, lifecycle, shape status, and place-specific data-pack and geometry-family availability with executable next calls. It does not list the global catalog and does not return polygon coordinates; use get_catalog to browse everything or get_geometry for shapes. Set include_hierarchy for same-release ancestors and include_references for maintained external or cross-family connections. Historical records are never replaced automatically. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| iso3 | No | Optional country hint for crosswalk artifacts. Defaults to the loc_id country when possible. | |
| loc_id | No | DaedalMap loc_id, e.g. 'USA-CA'. | |
| loc_ids | No | DaedalMap loc_ids to inspect together, including every loc_id from a resolve_point stack. Default public cap is deployment-configurable. | |
| systems | No | Optional reference systems to include when include_references is true, such as zcta, nws_fire, overlay_tribal, or overlay_nws_public_zone. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| min_share | No | Optional minimum target-area share for reverse overlap references. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| limit_per_system | No | Maximum overlap references to return per bridge/system. Default 10. | |
| include_hierarchy | No | When true, include strict stored parent and ancestor data. This never invents a parent edge across mixed releases. Default false. | |
| include_references | No | When true, include known external or side-chain references attached to each loc_id. Default false. | |
| target_admin_level | No | Admin level for crosswalk-backed reverse reference lookup. Inferred when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| iso3 | No | |
| name | No | |
| error | No | |
| family | No | |
| loc_id | No | |
| reason | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| hierarchy | No | |
| next_step | No | |
| data_packs | No | |
| next_calls | No | |
| references | No | |
| request_id | No | |
| admin_level | No | |
| found_count | No | |
| loc_id_count | No | |
| clarification | No | |
| meter_receipt | No | |
| missing_count | No | |
| requested_loc_id | No | |
| geometry_families | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: 'Historical records are never replaced automatically' and 'No payment required.' This enriches the agent's understanding of side effects and constraints.
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 given the tool's complexity. It front-loads the purpose, then scopes usage, then lists exclusions, then mentions key flags and behavioral caveats. Every sentence serves a distinct function, though the phrase 'executable next calls' is slightly vague and could be clearer.
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 an 11-parameter tool with an output schema and strong annotations, the description covers the return contents, usage conditions, exclusions, and important behavioral notes (historical record handling, payment). The only minor gap is the vague 'executable next calls,' but overall it is comprehensive enough for correct invocation.
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 schema fully documents all 11 parameters. The description only mentions include_hierarchy and include_references in passing, without adding semantics beyond the schema. Baseline 3 applies because the schema does the heavy lifting and the description adds minimal extra parameter guidance.
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?
States a specific purpose: 'Known-place navigation and enrichment tool' and lists what it returns (identity, strict stored parentage, lifecycle, shape status, data-pack/geometry availability). Clearly distinguishes from siblings by noting it does not list the global catalog and does not return polygon coordinates, naming get_catalog and get_geometry as the appropriate alternatives.
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?
Explicitly sets the precondition: 'use only when you already have one canonical loc_id or a bounded loc_ids array.' Also provides when-not guidance ('does not list the global catalog') and names the alternatives (get_catalog, get_geometry). This is unambiguous usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packInspect One Selected Pack or Geometry FamilyARead-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 declare readOnly/idempotent/non-destructive, and the description adds behavioral value by revealing that results include a next_step for progression and that detail levels map to lite vs full metadata vs download URL. This goes beyond what annotations alone 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?
Two tight sentences front-load the core purpose and then give the key follow-up behavior. There is no filler or redundant restatement of the schema.
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 a rich input schema and an output schema, the description covers the essential workflow and progression. The only mild gap is that 'preferred geometry tool' is not named explicitly, but the sibling list and schema make the intended routing reasonably discoverable.
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 schema already documents all parameters in detail. The description adds only mild semantic framing ('lite starter contract') and mostly restates the detail-level behavior already present in the schemas.
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 a specific verb, 'Inspect', and a specific resource, 'one selected data pack or geometry family', and names three progressive modes (lite, full, download). It also differentiates from siblings by framing get_pack as operating on a single selected item while get_catalog lists and get_data retrieves 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?
The description gives actionable guidance: use it to inspect a selected pack, and then 'Use its next_step to retrieve data or call the preferred geometry tool.' It implies a sequential workflow but does not explicitly state when to prefer get_data or get_catalog instead, so it falls just 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_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.
identify_dataset_geographyChoose Geography Columns From a DatasetARead-onlyIdempotentInspect
Multi-column dataset classifier: use when you do not yet know which column or latitude/longitude pair represents geography. Pass bounded samples from several named scalar columns; it selects the plausible geography column(s), then proposes a country, level, and maintained reference-system binding. It does not validate a preselected identifier column value-by-value; after selecting a code column, use identify_reference_system when explicit verification is needed. Returns up to three reviewable bindings and recommends only an unambiguous high-confidence result. No geometry is loaded and no full dataset is retained. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| columns | Yes | Structurally filtered columns with deterministic representative scalar values. Do not pre-label their geographic system. | |
| request_id | No | ||
| country_scope | No | Optional caller-declared ISO3 hint. Omit when unknown. | |
| dataset_context | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| limit | No | |
| reason | No | |
| status | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| candidates | No | |
| request_id | No | |
| column_count | No | |
| clarification | No | |
| meter_receipt | No | |
| review_required | No | |
| identifier_count | No | |
| coordinate_binding | No | |
| settlement_receipt | No | |
| recommended_binding | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: it returns up to three reviewable bindings, recommends only unambiguous high-confidence results, loads no geometry, retains no full dataset, and requires no payment. This gives agents a clear picture of operational side effects.
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 dense but every sentence earns its place. The opening phrase frames the tool as a classifier and the primary use case, followed by concrete operational details, exclusions, and output characteristics. No filler or redundant restatement of the title.
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 and the presence of an output schema, the description covers the essential call context: when to use, what to pass, what it returns (up to three bindings, no geometry loaded), and how it relates to a sibling tool. The only not-explicitly-stated edge cases (e.g., ambiguous input) are adequately hinted by 'recommends only an unambiguous high-confidence result.'
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 only 50%, so the description compensates by explaining the meaning of the core 'columns' parameter: pass bounded samples from several named scalar columns, and do not pre-label their geographic system. It also clarifies country_scope as an ISO3 hint. However, request_id and dataset_context are not elaborated in the description, leaving some params undocumented.
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?
States a specific verb ('selects', 'proposes') and a precise resource ('geography columns from a dataset'). It clearly differentiates from the sibling identify_reference_system by explaining this tool is for discovering geography columns when unknown, not for validating a preselected code column.
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?
Explicitly says 'use when you do not yet know which column or latitude/longitude pair represents geography.' It also names the alternative (identify_reference_system) and the condition for switching (after selecting a code column, when explicit verification is needed). No ambiguity about when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identify_reference_systemIdentify One Identifier Column's Reference SystemARead-onlyIdempotentInspect
Single-column code-system classifier: use after an identifier column has already been selected, or to inspect one bounded set of like geography codes. Pass only identifier strings from that one field so leading zeros are preserved. It determines or verifies the system, country, level, vintage, and compatible geometry bank; it does not choose among dataset columns, convert the full dataset, or return polygons. Use identify_dataset_geography instead when column selection is still unknown. Ambiguous results remain unselected until the caller retries with expected.system; a known system can be verified by supplying expected on the first call. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| expected | No | ||
| identifier | No | One geography identifier to inspect. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| identifiers | No | A bounded representative identifier sample. Duplicate values are checked once. Values must be strings so leading zeros are preserved. | |
| country_scope | No | Optional ISO3 country hint used to narrow candidate banks. | |
| dataset_context | No | Bounded, non-row dataset clues used to rank plausible interpretations without replacing exact identifier verification. | |
| validation_scope | No | Describes whether the bounded input is a sample or, only when it fits the identification cap, the complete distinct-key set. This tool validates every supplied identifier; create_conversion_job validates every row in the full dataset. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| limit | No | |
| reason | No | |
| status | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| candidates | No | |
| request_id | No | |
| column_count | No | |
| clarification | No | |
| meter_receipt | No | |
| review_required | No | |
| identifier_count | No | |
| coordinate_binding | No | |
| settlement_receipt | No | |
| recommended_binding | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds substantial context: 'No payment required', 'does not choose among dataset columns, convert the full dataset, or return polygons', and the retry behavior for ambiguous results. It also explains that input values must be strings to preserve leading zeros. These add real value beyond the annotations and clarify what the tool will and won't do.
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 dense but every sentence earns its place: purpose, usage condition, input guidance, scope exclusions, alternative routing, retry behavior, and payment. It is front-loaded with the core purpose and has no fluff or 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 tool with 7 parameters, nested objects, anyOf constraints, and an output schema, the description covers selection logic, input constraints, behavioral exclusions, and alternative routing. The output schema handles return details, and the description leaves no critical gap for an agent deciding whether and how to call it.
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 86%, so the baseline is 3. The description adds meaningful guidance: passing only strings from one field to preserve leading zeros, using expected.system for verification or retry, and clarifying dataset_context as 'bounded, non-row dataset clues' and validation_scope as covering every supplied identifier. These clarifications go beyond the schema, though they don't enumerate every parameter.
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?
States it is a 'single-column code-system classifier' and lists exactly what it determines (system, country, level, vintage, compatible geometry bank). Explicitly distinguishes from identify_dataset_geography by naming the sibling and the condition that selects it. The verb and resource are specific and unambiguous.
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 when-to-use ('use after an identifier column has already been selected, or to inspect one bounded set') and when-not ('Use identify_dataset_geography instead when column selection is still unknown'). Also instructs to pass only identifier strings to preserve leading zeros and explains how to use expected for verification or retry. Clear, actionable guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_deep_pointResolve Point(s) (Deep)ARead-onlyIdempotentInspect
Second-pass resolution for one WGS84 coordinate or a bounded point array. Supply one shared shallow_loc_id returned by resolve_point and one canonical family from get_catalog(catalog='geometry'). family defaults to administrative; shape-backed families use direct bbox-to-exact-shape lookup without crosswalks. Single and bulk requests share this scoped contract.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude in WGS84 decimal degrees. | |
| lon | No | Longitude in WGS84 decimal degrees. | |
| family | No | One family selector. Defaults to administrative; use marine for the direct Marine resolver, or a canonical country family such as postal_area, watershed, or land_management_region. | administrative |
| points | No | Points already known to fall within the supplied shallow_loc_id scope. | |
| batch_id | No | Optional caller-supplied batch id echoed for point arrays. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| shallow_loc_id | Yes | The deepest canonical Admin 1-3 loc_id returned by resolve_point, such as USA-NY-061-009903. | |
| target_admin_level | No | Optional exact Admin 4-6 level. Omit for the deepest available match. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| point | No | |
| stack | No | |
| family | No | |
| reason | No | |
| matched | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| join_keys | No | |
| next_step | No | |
| request_id | No | |
| point_count | No | |
| clarification | No | |
| family_result | No | |
| meter_receipt | No | |
| resolved_count | No | |
| shallow_loc_id | No | |
| deeper_available | No | |
| overlap_families | No | |
| unresolved_count | No | |
| settlement_receipt | No | |
| deepest_resolved_family | No | |
| deepest_resolved_loc_id | No | |
| deepest_resolved_admin_level | No | |
| available_deeper_admin_levels | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: family defaults to administrative, shape-backed families use direct bbox-to-exact-shape lookup without crosswalks, and single and bulk requests share the same scoped contract. This goes beyond what annotations alone 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?
Three dense sentences with no filler. The purpose is front-loaded, and each sentence adds distinct value: what it does, what inputs it needs, and how family selection affects behavior.
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 and rich annotations, the description is largely sufficient. It covers the tool's role, prerequisites, defaults, and the shared single/bulk contract. Minor missing context includes explicit error or edge-case behavior, but this is not essential for correct tool selection and invocation.
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 baseline is 3. The description adds value by explaining that family comes from get_catalog, defaults to administrative, and that shape-backed families bypass crosswalks. It also clarifies that shallow_loc_id is the output of resolve_point, giving provenance not fully captured in 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 states a specific verb ('resolve') and resource ('one WGS84 coordinate or a bounded point array') and identifies itself as 'Second-pass resolution' relative to resolve_point. This clearly distinguishes it from sibling tools like resolve_point or get_geometry.
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 explicitly says to supply a shallow_loc_id returned by resolve_point and a family from get_catalog(catalog='geometry'), establishing clear prerequisites and context. It does not enumerate explicit when-not-to-use conditions or name alternative tools, but the second-pass framing makes the usage boundary clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_pointResolve Point(s) (Shallow)ARead-onlyIdempotentInspect
Compact first-pass reverse geocoding for one WGS84 coordinate or a bounded point array. Returns administrative loc_id chains through Admin 3 without opening deep partitions or side-family shape banks. Use a returned shallow loc_id with resolve_deep_point for Admin 4-6 or one explicit family. Single and bulk requests share this contract; access limits are based on point count.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude in WGS84 decimal degrees. | |
| lon | No | Longitude in WGS84 decimal degrees. | |
| points | No | Bounded WGS84 point array. Use top-level lat/lon instead for one point. | |
| batch_id | No | Optional caller-supplied batch id echoed for point arrays. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| target_admin_level | No | Optional exact requested level from Admin 0-3. Omit it to return the deepest available shallow level. | |
| include_marine_context | No | Include parallel Marine overlaps for land matches. Defaults to true; set false for fast administrative loc_id previews. Offshore Marine fallback still applies. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| point | No | |
| stack | No | |
| family | No | |
| reason | No | |
| matched | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| join_keys | No | |
| next_step | No | |
| request_id | No | |
| point_count | No | |
| clarification | No | |
| family_result | No | |
| meter_receipt | No | |
| resolved_count | No | |
| shallow_loc_id | No | |
| deeper_available | No | |
| overlap_families | No | |
| unresolved_count | No | |
| settlement_receipt | No | |
| deepest_resolved_family | No | |
| deepest_resolved_loc_id | No | |
| deepest_resolved_admin_level | No | |
| available_deeper_admin_levels | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: performance characteristics (does not open deep partitions or side-family shape banks), access limits tied to point count, and details about marine context fallback. 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?
Three sentences with no redundant phrasing. The core purpose is front-loaded, the alternative tool is mentioned early, and the contract details are kept brief. Every sentence adds essential 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?
The tool has a multi-modal contract (single vs bulk) and 7 parameters, but the description covers the fundamental usage pattern, naming the exact sibling for deeper resolution, and the access-limit rationale. With an output schema present, no return format explanation is needed. All critical information for correct invocation is present.
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 all 7 parameters, so the schema already explains each parameter. The description adds minimal extra meaning: it clarifies the dual mode (single vs bulk) and the purpose of target_admin_level and include_marine_context, but these are also described in the schema. Baseline 3 is appropriate since the description adds limited value over the structured 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?
States a specific verb ('reverse geocoding') and resource ('one WGS84 coordinate or a bounded point array'), and clearly scopes the output ('administrative loc_id chains through Admin 3'). Explicitly contrasts with the sibling resolve_deep_point by naming the data partitions it avoids, making the tool easily distinguishable.
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 when-to-use guidance: 'first-pass reverse geocoding' and 'without opening deep partitions' indicates the shallow use case, and directly instructs to 'Use a returned shallow loc_id with resolve_deep_point for Admin 4-6 or one explicit family.' Also notes that single and bulk requests share a contract, clarifying invocation patterns.
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.
9 tool updates
v1.0.1- Changed
compare_geographies1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "spatial_relation" + ] + }, + { + "required": [ + "item_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "compared_count": { + "minimum": 0, + "type": "integer" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "failed_count": { + "minimum": 0, + "type": "integer" + }, + "guidance": { + "type": "object" + }, + "item_count": { + "minimum": 0, + "type": "integer" + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "spatial_relation": { + "type": [ + "string", + "object", + "null" + ] + }, + "temporal_relation": { + "type": [ + "string", + "object", + "null" + ] + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
convert_reference1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "results" + ] + }, + { + "required": [ + "item_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "converted_count": { + "minimum": 0, + "type": "integer" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "from": { + "type": "object" + }, + "from_system": { + "type": "string" + }, + "guidance": { + "type": "object" + }, + "item_count": { + "minimum": 0, + "type": "integer" + }, + "loc_id": { + "type": [ + "string", + "null" + ] + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "to_system": { + "type": "string" + }, + "unconverted_count": { + "minimum": 0, + "type": "integer" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_data13 fields changed- added
Input schema / properties / filters / additionalPropertiesAdded value: +{ + "anyOf": [ + { + "type": [ + "string", + "number", + "integer", + "boolean", + "null" + ] + }, + { + "items": { + "type": [ + "string", + "number", + "integer", + "boolean" + ] + }, + "type": "array" + } + ] +} - removed
Input schema / properties / filters / descriptionRemoved value: -"Structured filters including time, region_ids, and compare clauses." - added
Input schema / properties / filters / propertiesAdded value: +{ + "compare": { + "description": "Threshold filters using filterable fields or selected metric ids published by get_pack.", + "items": { + "additionalProperties": false, + "properties": { + "field": { + "minLength": 1, + "type": "string" + }, + "op": { + "enum": [ + "=", + "!=", + ">", + ">=", + "<", + "<=" + ], + "type": "string" + }, + "value": {} + }, + "required": [ + "field", + "op", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "equals": { + "additionalProperties": { + "anyOf": [ + { + "type": [ + "string", + "number", + "integer", + "boolean", + "null" + ] + }, + { + "items": { + "type": [ + "string", + "number", + "integer", + "boolean" + ] + }, + "type": "array" + } + ] + }, + "description": "Exact field/value filters using filterable fields published by get_pack.", + "type": "object" + }, + "region_ids": { + "description": "Canonical country or hierarchical loc_ids from get_pack, such as JPN or USA-TX.", + "items": { + "minLength": 1, + "type": "string" + }, + "minItems": 1, + "type": "array", + "uniqueItems": true + }, + "time": { + "additionalProperties": false, + "anyOf": [ + { + "required": [ + "value" + ] + }, + { + "required": [ + "start" + ] + }, + { + "required": [ + "end" + ] + } + ], + "description": "Inclusive ISO-8601 date/datetime or integer-year selection. Use YYYY-MM-DD, not partial YYYY-MM strings.", + "properties": { + "end": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "format": "date", + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "granularity": { + "enum": [ + "daily", + "weekly", + "monthly", + "yearly", + "timestamp" + ], + "type": "string" + }, + "start": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "format": "date", + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "value": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "format": "date", + "type": "string" + }, + { + "type": "integer" + } + ] + } + }, + "type": "object" + } +} - changed
Input schema / properties / metrics / descriptionPrevious value: -"Metric ids to return. Use event_count for aggregate counts when supported."New value: +"Exact metric ids from get_pack. Use event_count for aggregate counts only when get_pack publishes it." - added
Input schema / properties / metrics / items / minLengthAdded value: +1 - added
Input schema / properties / metrics / minItemsAdded value: +1 - added
Input schema / properties / metrics / uniqueItemsAdded value: +true - added
Input schema / properties / output / additionalPropertiesAdded value: +false - changed
Input schema / properties / output / descriptionPrevious value: -"Optional output controls such as response format hints."New value: +"Optional response controls. v1 supports rows only." - added
Input schema / properties / output / propertiesAdded value: +{ + "format": { + "default": "rows", + "enum": [ + "rows" + ], + "type": "string" + }, + "include_provenance": { + "default": false, + "type": "boolean" + } +} - added
Input schema / properties / pack_id / minLengthAdded value: +1 - changed
Input schema / properties / sort / anyOfPrevious value: -[ - { - "type": "array" - }, - { - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "direction": { + "enum": [ + "asc", + "desc" + ], + "type": "string" + }, + "field": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + { + "items": { + "additionalProperties": false, + "properties": { + "direction": { + "enum": [ + "asc", + "desc" + ], + "type": "string" + }, + "field": { + "minLength": 1, + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + } +] - changed
Input schema / properties / sort / descriptionPrevious value: -"Optional sort instructions for row-returning queries."New value: +"Sort by a sortable field from get_pack; direction defaults to asc."
- Changed
get_geometry1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "selection", + "items" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "available": { + "minimum": 0, + "type": "integer" + }, + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "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" + }, + "include_polygon": { + "type": "boolean" + }, + "items": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "meter_receipt": { + "type": "object" + }, + "missing": { + "minimum": 0, + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "requested": { + "minimum": 0, + "type": "integer" + }, + "scope": { + "type": [ + "object", + "null" + ] + }, + "selection": { + "enum": [ + "exact_loc_ids", + "admin_scope" + ], + "type": "string" + }, + "settlement_receipt": { + "type": "object" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_loc_id_info1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "loc_id" + ] + }, + { + "required": [ + "loc_id_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "admin_level": { + "type": [ + "string", + "integer", + "null" + ] + }, + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "data_packs": { + "type": "array" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "family": { + "type": [ + "string", + "null" + ] + }, + "found_count": { + "minimum": 0, + "type": "integer" + }, + "geometry_families": { + "type": "array" + }, + "guidance": { + "type": "object" + }, + "hierarchy": { + "type": "object" + }, + "iso3": { + "type": [ + "string", + "null" + ] + }, + "loc_id": { + "type": "string" + }, + "loc_id_count": { + "minimum": 0, + "type": "integer" + }, + "meter_receipt": { + "type": "object" + }, + "missing_count": { + "minimum": 0, + "type": "integer" + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "next_calls": { + "type": "array" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "references": { + "type": "object" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "requested_loc_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
identify_dataset_geography1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "status", + "candidates" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "candidates": { + "items": { + "type": "object" + }, + "type": "array" + }, + "clarification": { + "type": "object" + }, + "column_count": { + "minimum": 0, + "type": "integer" + }, + "coordinate_binding": { + "type": [ + "object", + "null" + ] + }, + "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" + }, + "identifier_count": { + "minimum": 0, + "type": "integer" + }, + "limit": { + "minimum": 0, + "type": "integer" + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "recommended_binding": { + "type": [ + "object", + "null" + ] + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "review_required": { + "type": "boolean" + }, + "settlement_receipt": { + "type": "object" + }, + "status": { + "type": "string" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
identify_reference_system1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "status", + "candidates" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "candidates": { + "items": { + "type": "object" + }, + "type": "array" + }, + "clarification": { + "type": "object" + }, + "column_count": { + "minimum": 0, + "type": "integer" + }, + "coordinate_binding": { + "type": [ + "object", + "null" + ] + }, + "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" + }, + "identifier_count": { + "minimum": 0, + "type": "integer" + }, + "limit": { + "minimum": 0, + "type": "integer" + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "recommended_binding": { + "type": [ + "object", + "null" + ] + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "review_required": { + "type": "boolean" + }, + "settlement_receipt": { + "type": "object" + }, + "status": { + "type": "string" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
resolve_deep_point1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "point", + "stack" + ] + }, + { + "required": [ + "point", + "family", + "family_result" + ] + }, + { + "required": [ + "point_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "available_deeper_admin_levels": { + "type": "array" + }, + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "deeper_available": { + "type": "boolean" + }, + "deepest_resolved_admin_level": { + "type": [ + "string", + "integer", + "null" + ] + }, + "deepest_resolved_family": { + "type": [ + "string", + "null" + ] + }, + "deepest_resolved_loc_id": { + "type": [ + "string", + "null" + ] + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "family": { + "type": "string" + }, + "family_result": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "join_keys": { + "type": "object" + }, + "matched": { + "type": [ + "object", + "null" + ] + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "overlap_families": { + "items": { + "type": "object" + }, + "type": "array" + }, + "point": { + "anyOf": [ + { + "additionalProperties": true, + "properties": { + "lat": { + "type": "number" + }, + "lon": { + "type": "number" + } + }, + "required": [ + "lat", + "lon" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "point_count": { + "minimum": 0, + "type": "integer" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "resolved_count": { + "minimum": 0, + "type": "integer" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "shallow_loc_id": { + "type": "string" + }, + "stack": { + "items": { + "type": "object" + }, + "type": "array" + }, + "unresolved_count": { + "minimum": 0, + "type": "integer" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
resolve_point1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "point", + "stack" + ] + }, + { + "required": [ + "point", + "family", + "family_result" + ] + }, + { + "required": [ + "point_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "available_deeper_admin_levels": { + "type": "array" + }, + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "deeper_available": { + "type": "boolean" + }, + "deepest_resolved_admin_level": { + "type": [ + "string", + "integer", + "null" + ] + }, + "deepest_resolved_family": { + "type": [ + "string", + "null" + ] + }, + "deepest_resolved_loc_id": { + "type": [ + "string", + "null" + ] + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "family": { + "type": "string" + }, + "family_result": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "join_keys": { + "type": "object" + }, + "matched": { + "type": [ + "object", + "null" + ] + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "overlap_families": { + "items": { + "type": "object" + }, + "type": "array" + }, + "point": { + "anyOf": [ + { + "additionalProperties": true, + "properties": { + "lat": { + "type": "number" + }, + "lon": { + "type": "number" + } + }, + "required": [ + "lat", + "lon" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "point_count": { + "minimum": 0, + "type": "integer" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "resolved_count": { + "minimum": 0, + "type": "integer" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "shallow_loc_id": { + "type": "string" + }, + "stack": { + "items": { + "type": "object" + }, + "type": "array" + }, + "unresolved_count": { + "minimum": 0, + "type": "integer" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
20 tool updates
- Added
compare_geographies - Added
convert_reference - Changed
get_catalog6 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" +} - 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" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "catalog", + "detail" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "catalog": { + "enum": [ + "data", + "geometry" + ], + "type": "string" + }, + "catalog_version": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "detail": { + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" + }, + "download_url": { + "type": "string" + }, + "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, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "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" +}
- Added
get_data - Removed
get_earthquake_events - Added
get_event - Removed
get_fx_rates - Added
get_geometry - Removed
get_live_earthquake_events - Removed
get_live_volcano_events - Added
get_loc_id_info - Changed
get_pack6 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" +} - added
Input schema / properties / detailAdded value: +{ + "default": "lite", + "description": "Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file.", + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" +} - 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 from get_catalog. Newly catalog-admitted packs require no MCP schema change." - 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 / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "catalog", + "pack_id", + "detail" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "catalog": { + "enum": [ + "data", + "geometry" + ], + "type": "string" + }, + "clarification": { + "type": "object" + }, + "detail": { + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" + }, + "download_call": { + "type": "object" + }, + "download_url": { + "type": "string" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "full_call": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "material_policy": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "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" +}
- Added
get_tool_help - Removed
get_tsunami_events - Removed
get_volcanic_activity - Added
identify_dataset_geography - Added
identify_reference_system - Removed
query_dataset - Added
resolve_deep_point - Added
resolve_point
9 tool updates
v1.0.0- First observed
get_catalog - First observed
get_earthquake_events - First observed
get_fx_rates - First observed
get_live_earthquake_events - First observed
get_live_volcano_events - First observed
get_pack - First observed
get_tsunami_events - First observed
get_volcanic_activity - First observed
query_dataset
TDQS
Scored across 13 tools
Every tool targets a clearly distinct action and data type: catalog exploration, pack inspection, place info, geometry retrieval, point resolution, identity conversion, event drill-down, and two different classifier modes. Descriptions explicitly cross-reference when to use other tools, reducing overlap confusion.
All names follow a predictable lowercase snake_case pattern with a leading verb: get_* for retrievals, identify_* for classification, resolve_* for geocoding, plus convert/compare for specific operations. The verb-prefix convention makes the tool family immediately understandable.
Thirteen tools is well within the 3-15 sweet spot and matches the breadth of the geospatial domain: catalog discovery, pack access, geometry, reference conversion, point resolution, and event lookup all earn their place without feeling bloated.
The tool set covers the full read-only workflow for a geographic data platform: discover, inspect, retrieve data and geometry, resolve points, classify and verify identifiers, convert references, compare geographies, and drill into events. No obvious dead ends or missing operations for the apparent domain.
Maintenance
Related MCP Connectors
- earthOAuthcom.mireye
MCP server for Mireye Earth — federal-source-cited geospatial data for any MCP-aware agent.
Geocodio MCP — wraps the Geocodio geocoding API (geocod.io)
Free GeoNames MCP: countries, cities, POIs, distance & nearby. Remote HTTP + agent token signup.
Regrid MCP — wraps the Regrid Parcel API v2 (regrid.com)
Related MCP Servers
- AlicenseCqualityAmaintenanceA Model Context Protocol server that connects LLMs to GIS operations, enabling AI assistants to perform accurate geospatial analysis including geometric operations, coordinate transformations, and spatial measurements.87195MIT
- AlicenseBqualityAmaintenanceEnables AI assistants to search and access geospatial datasets through STAC (SpatioTemporal Asset Catalog) APIs. Supports querying satellite imagery, weather data, and other geospatial assets with spatial, temporal, and attribute filters.1118MIT
- AlicenseAqualityDmaintenanceProvides comprehensive geospatial analysis capabilities through Turf.js, enabling spatial measurements, geometric operations, coordinate transformations, and geographic data processing. Supports over 100 geospatial functions including distance calculations, spatial relationships, buffer operations, and grid generation.100MIT
- FlicenseAqualityDmaintenanceProvides access to the OpenLandMap STAC catalog, offering over 100 global environmental datasets including soil, climate, and vegetation data. It enables AI agents to discover, search, and retrieve Cloud-Optimized GeoTIFFs for global geospatial analysis.27-