DaedalMap Disaster and Geospatial Data
Server Details
Geospatial MCP server for earthquake, tsunami, volcano, disaster, and FX data queries.
- Status
- Healthy
- Uptime
- 95.7% over 36 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
- Repository
- xyver/daedal-map
- GitHub Stars
- 2
- Server Listing
- daedal-map
TDQS
Scored across 13 tools
Most tools have clearly distinct purposes, especially the get_*, resolve_*, and identify_* families. The main ambiguity is between identify_dataset_geography, identify_reference_system, and convert_reference, though their descriptions draw reasonable boundaries around dataset-level identification, identifier-level identification, and known-system conversion.
All tool names follow a consistent snake_case verb_noun convention: get_catalog, get_data, get_pack, identify_reference_system, resolve_point, compare_geographies, convert_reference. The naming pattern makes the tool families and their roles predictable.
Thirteen tools is well within the ideal range for a server covering disaster data retrieval, geospatial hierarchy, reference conversion, and reverse geocoding. Each tool appears to earn its place, with no obvious redundant entries.
The tool surface covers the core workflows well: discovering catalogs, inspecting packs, retrieving data rows, drilling into events, resolving identifiers, converting references, fetching geometries, comparing geographies, and reverse geocoding. Since this is a read-only data/geospatial server, the lack of create/update/delete tools is appropriate rather than a gap.
Available Tools
13 toolscompare_geographiesCompare Geographic IdentitiesARead-onlyInspect
Smart relationship tool for two geographic identities. It answers canonical Admin Spine containment and common ancestry directly from loc_id paths, then checks maintained crosswalk evidence between different families, and loads polygons only when those cheaper sources cannot answer the spatial question. Exact geometry fallback returns topology, geodesic intersection area, and directional overlap shares. Temporal validity and N-way successor context remain independent of the spatial evidence source. 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read operation, and the description goes beyond it by exposing the internal decision flow: cheap loc_id path answers first, crosswalk evidence second, polygon geometry only as fallback. It also discloses the return categories (topology, geodesic intersection area, directional overlap shares) and notes that temporal validity and successor context are independent of the evidence source — useful behavioral context not present in the schema or 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?
Five sentences, each carrying a distinct piece of information: core purpose, fast-path sources, geometry fallback, return content, and a routing hint. It is dense and front-loaded. The only minor waste is the vague opener 'Smart relationship tool' and the somewhat redundant 'No payment required' note, but they do not meaningfully hurt readability.
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 complex comparison tool with 9 parameters, no output schema, and many siblings, the description covers the processing pipeline, fallback behavior, and key return values. It does not describe the outbound shape of the result structure, but the mention of topology, area, and overlap shares gives the agent enough grounding to invoke it and interpret the response. The annotation already covers the read-only safety profile.
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 parameters are already fully documented. The description adds domain framing around loc_id paths and temporal validity, but it does not explain individual parameter formats, defaults, or the anyOf batching structure beyond what the schema already provides. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation — comparing two geographic identities — and details exactly what kinds of relationships it answers (Admin Spine containment, common ancestry, crosswalk evidence, polygon overlap). This makes it clearly distinguishable from sibling tools like resolve_point, get_geometry, and identify_reference_system, all of which solve different problems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a direct routing instruction: 'Use convert_reference first for names or outside identifiers.' This tells the agent when a sibling tool is the right antecedent. It implies this tool should be used for loc_id-based comparisons, though it does not exhaustively enumerate when not to use other geometry or resolution tools.
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-onlyInspect
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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the internal X -> loc_id -> Y conversion chain, bounded-list handling, and the fact that no payment is required. It does not describe ranking or response details, but the read-only safety profile is already covered by 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?
Four short, front-loaded sentences with no wasted words. The core conversion model, routing advice, and payment note each earn their place, and there is no repetition of schema content.
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 14-parameter tool with no output schema, the description covers the essential call patterns, the prerequisite get_pack step, and the conversion output concept. It leaves ranking and detailed row behavior to the schema, which is complete, so the gaps are modest.
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 semantics for to_system by explaining the 'loc_id universe' and when to omit versus provide it, which goes beyond the field-level schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action (converts a geographic reference) and the scope (one reference or a bounded list) with a specific conversion path through DaedalMap loc_id. It does not explicitly differentiate from siblings like create_conversion_job, though 'single converter' gestures at uniqueness.
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-selection guidance: omit to_system to enter the loc_id universe, provide it for any-to-any conversion, and use get_pack first when the family or country-specific system is unknown. This gives an agent actionable routing beyond what the schema provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_catalogGet CatalogARead-onlyIdempotentInspect
Discover data packs or geometry families progressively: lite selection, full metric/query inventory, or a raw catalog download URL. Choose one result and call get_pack next. Current catalog: The same geography tools work worldwide across a cataloged baseline of 252 geographic entities, reaching up to Admin 2. Where additional country releases are available, the same calls automatically return deeper administrative tiers or maintained reference families. Additional detail is currently available for Australia, Brazil, Canada, France, Germany, Mexico, United Kingdom, United States.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Use lite to select a pack, full for expanded metric/query inventories, or download for the complete raw catalog URL. | lite |
| catalog | No | Catalog family. The geography facade defaults to geometry; other facades default to data. | data |
| 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, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the catalog is progressive, the same calls automatically return deeper tiers for certain countries, and the current catalog baseline is 252 geographic entities up to Admin 2. This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence stating the tool's purpose, followed by a useful catalog context paragraph. It's slightly verbose with the country list, but every sentence adds meaningful context about scope and behavior. The key usage guidance 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 output schema exists and annotations cover safety, the description is fairly complete. It explains the progressive discovery flow, names the next step (get_pack), and describes the catalog scope. Minor gap: it doesn't explicitly describe what the output schema contains, but the output schema itself covers that. It could also clarify when to use get_data vs get_catalog, but the sibling context is minimal.
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 already documents all three parameters thoroughly. The description adds context about the progressive discovery flow and country scope behavior, but doesn't add significant new parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: discover data packs or geometry families progressively, with three levels of detail (lite, full, download). It distinguishes itself from siblings by explicitly saying to call get_pack next after choosing a result, and the catalog parameter differentiates data vs geometry families.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use lite to select a pack, full for expanded inventories, download for raw catalog URL. It names get_pack as the next step. However, it doesn't explicitly contrast with get_data or get_tool_help, though the progressive discovery flow is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dataGet DataARead-onlyIdempotentInspect
Retrieve rows from one selected published data pack using exact metrics, loc_id-based region filters, time/metric filters, sorting, and a row limit. Disaster event rows include stable event_id values for get_event drill-down. A parent administrative loc_id selects matching descendant rows at the pack's published grain. Call get_pack first; geometry families use their focused next-step tools.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Optional sort instructions for row-returning queries. | |
| limit | No | Maximum number of rows to return for the requested source or pack. | |
| output | No | Optional output controls such as response format hints. | |
| filters | Yes | Structured filters including time, region_ids, and compare clauses. | |
| metrics | Yes | Metric ids to return. Use event_count for aggregate counts when supported. | |
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. | |
| request_id | No | Optional caller-supplied request id for tracing and idempotency. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | No | |
| sort | No | |
| error | No | |
| limit | No | |
| reason | No | |
| pack_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| row_count | No | |
| source_id | No | |
| truncated | No | |
| provenance | No | |
| query_mode | No | |
| request_id | No | |
| capability_id | No | |
| clarification | No | |
| filters_applied | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, and the description aligns with these by not suggesting modifications. It adds useful behavior beyond annotations, such as explaining that disaster event rows include stable event_id values and that parent loc_id selects descendant rows, which are non-obvious behaviors. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loads the core query capabilities before mentioning drill-down specifics. It is well-structured and every sentence adds meaningful information, but it could be slightly more structured with bullet points for clarity, though not necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, output schema), the description covers the main usage pattern but omits details like the output schema structure, which is available separately. It provides enough context for correct invocation, though it could mention the need for the pack_id to come from get_catalog as mentioned in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for all parameters, but the description adds semantic context beyond the schema, such as clarifying that metrics use event_count for aggregate counts and that loc_id filters work hierarchically. This goes beyond the schema's basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves rows from a single published data pack with specific filtering, sorting, and limit capabilities. It distinguishes itself from siblings by mentioning the need to call get_pack first and noting that geometry families have focused next-step tools, which helps differentiate from get_catalog and get_tool_help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use this tool, such as requiring get_pack to be called first and indicating that geometry families should use other tools. However, it does not explicitly state when not to use this tool or directly name alternative tools for geometry cases, so it's slightly below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_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_geometryGet loc_id GeometryARead-onlyInspect
Availability check and bounded shape retrieval for exact loc_ids or one administrative scope. Exact selection accepts loc_id or loc_ids. Scope selection accepts parent_loc_id plus admin_level and uses the optimized Admin Spine layout: Admin 0-3 stays on one national bank, while deeper levels require an Admin 1 parent and stay on one deep partition. The default response is the fast preflight: it projects has_shape, shape metadata, centroid, and bounding box without reading polygon coordinates. Set include_polygon=true only when exact coordinates are needed. Independent geometry families are selected by exact loc_ids, not inferred as administrative descendants. Use get_loc_id_info for hierarchy, catalog coverage, or crosswalk details. 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the readOnlyHint annotation: it explains the default preflight response (shape metadata, centroid, bbox without polygon coordinates), the optional include_polygon for full GeoJSON, that historical geometry is returned first with no automatic successor substitution, and that no payment is required. These are non-obvious behaviors an agent must know to use the tool correctly.
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 well-structured and information-dense without fluff. It front-loads the core purpose, then logically flows through selection modes, default behavior, include_polygon guidance, selection rules, sibling tool reference, historical behavior, and payment status. Every sentence adds value, and the length is appropriate for the tool's complexity.
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 (multiple selection modes, admin level handling, preflight vs. full polygon, historical handling), the description covers all critical aspects: what the default response contains, when to request polygons, how selection works, which sibling to use for hierarchy, and the historical behavior. The absence of an output schema is compensated by explicit description of the preflight fields. Nothing an agent needs to invoke correctly 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?
With schema description coverage at 83%, the schema already documents most parameters. The description adds contextual meaning: it clarifies that include_polygon is only for exact coordinates, that loc_ids has a configurable cap (lower when include_polygon is true), and it explains the Admin Spine layout for scope selection. These enrich the schema's bare descriptions, earning a score above the baseline.
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 precise purpose: 'Availability check and bounded shape retrieval for exact loc_ids or one administrative scope.' It clearly identifies the resource (shape geometry) and distinguishes between exact and scope selection modes. It also names a sibling tool (get_loc_id_info) that covers different needs, making it unambiguous which tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states when to use exact vs. scope selection, when to set include_polygon (only when exact coordinates are needed), and explicitly tells the agent to 'Use get_loc_id_info for hierarchy, catalog coverage, or crosswalk details.' It also notes that independent geometry families must be selected by exact loc_ids, not inferred, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_loc_id_infoGet loc_id InformationARead-onlyInspect
The navigation and enrichment tool for one loc_id or a bounded loc_ids array. Its lightweight default returns identity, strict stored parentage, shape status, lifecycle fields, candidate data-pack coverage, available geometry families, and executable next calls without scanning data rows or polygon coordinates. Set include_hierarchy for the strict same-release ancestor chain and include_references for exact external or cross-family connections. Historical records are returned as requested and successors are never substituted automatically. Use get_data for rows, get_geometry for polygons, and compare_geographies for pairwise relationships. 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true is already present, and the description reinforces it without contradiction. It adds substantial behavioral context beyond the annotation: the 'lightweight default' that avoids scanning data rows or polygon coordinates, the 'strict stored parentage' and 'strict same-release ancestor chain' with no invented edges across mixed releases, and the explicit non-substitution of successors. These details give the agent a precise picture of the tool's side effects and guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and tightly packed, with no wasted words. It front-loads the core purpose, then details the default output, then flag behaviors, then historical handling, then alternative tools, and finally the payment note. Each sentence earns its place, and the structure flows logically from what the tool is to how to use it and when not to.
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 11 parameters and no output schema, the description covers all essential aspects: what it does, what it returns by default, which flags alter behavior, edge cases (historical, mixed releases), and alternatives. It does not describe the return format, but since there is no output schema, the burden shifts to the description to convey content, which it does thoroughly. The proxy for completeness is high.
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 every parameter already has a description. The tool description adds value by explaining the purpose of two key flags: include_hierarchy for 'strict same-release ancestor chain' and include_references for 'exact external or cross-family connections', plus the bounded nature of loc_ids. This goes beyond the schema's terse descriptions, though it doesn't elaborate on all 11 parameters. Given the high coverage, the description's extra context pushes it above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('navigation and enrichment tool') and resource ('one loc_id or a bounded loc_ids array'), and enumerates the exact default output fields (identity, parentage, shape status, lifecycle, data-pack coverage, geometry families, next calls). It also explicitly contrasts with siblings ('Use get_data for rows, get_geometry for polygons'), making differentiation clear without needing to inspect other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by naming three alternative tools (get_data, get_geometry, compare_geographies) and what each is for. It also includes important behavioral caveats: historical records are returned as requested, successors are never substituted automatically, and the loc_ids array is bounded with a configurable cap. This leaves no ambiguity about when to call this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packGet PackARead-onlyIdempotentInspect
Inspect one selected data pack or geometry family progressively: lite starter contract, full MCP query metadata, or a raw metadata download URL. Use its next_step to retrieve data or call the preferred geometry tool.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file. | lite |
| catalog | No | Metadata family. When omitted, geometry facades default to geometry and known geometry-family ids are inferred; all other calls default to data. | |
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. | |
| release_unit | No | Optional non-country geometry release unit such as GLOBAL or MARINE. Do not combine with country_scope. | |
| country_scope | No | Optional ISO3 country for a geometry family. Omit it to learn which countries publish the family; provide it for country-specific versions, vintages, levels, and artifacts. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| detail | No | |
| reason | No | |
| catalog | No | |
| pack_id | No | |
| sources | No | |
| guidance | No | |
| warnings | No | |
| full_call | No | |
| next_step | No | |
| provenance | No | |
| request_id | No | |
| download_url | No | |
| clarification | No | |
| download_call | No | |
| material_policy | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those hints: the progressive lite/full/download contract and the presence of a next_step handoff for further action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by the handoff behavior. Some jargon like 'starter contract' and 'preferred geometry tool' is vague, but the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Rich schema descriptions, an output schema, and safety annotations cover most operational details. The description still leaves the sibling relationship slightly implicit: it would be stronger if it explicitly named get_data or get_catalog and positioned get_pack in the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so pack_id, detail, catalog, release_unit, and country_scope are already well documented. The description restates the detail modes ('lite starter contract, full MCP query metadata, raw metadata download URL') but adds no new parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb+resource ('inspect one selected data pack or geometry family') and enumerates the three detail modes: lite, full, and download. 'Inspect' plus the reference to next_step separates it from catalog listing and direct data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a workflow: inspect a selected pack, then use next_step to retrieve data or call the preferred geometry tool. It never explicitly names get_catalog or get_data as alternatives, nor states when not to use this tool, leaving sibling routing implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tool_helpGet Tool HelpARead-onlyIdempotentInspect
Describe one tool visible on this facade, including its exact contract, or return a bounded workflow overview for one supported topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Workflow overview. Do not combine with tool_name. | |
| question | No | Optional question used only with a topic overview. | |
| tool_name | No | Exact tool name from tools/list. Do not combine with topic. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| title | No | |
| access | No | |
| reason | No | |
| purpose | No | |
| examples | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| tool_name | No | |
| provenance | No | |
| request_id | No | |
| input_schema | No | |
| clarification | No | |
| recommended_next_calls | No | |
| important_output_fields | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds a bit of behavioral context by mentioning 'exact contract' and 'bounded workflow overview', but it does not disclose potential error conditions or response formats. This is acceptable given the annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently presents both modes without redundancy. Every phrase adds value, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate but relies heavily on the schema for constraints (e.g., oneOf logic, enum values, mutual exclusivity). It does not mention optional parameters or edge cases, but given the rich schema and annotations, it covers the essential purpose. A 3 reflects that it is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a thorough description (e.g., 'Do not combine with tool_name'). The tool description adds no extra parameter detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: describe a tool (with its exact contract) or return a workflow overview for a supported topic. It uses specific verbs and resources, and the two modes are distinct. This differentiates it from sibling data-fetching tools like get_data and get_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use each mode by stating the two options, and the schema enforces mutual exclusivity. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., for actual data retrieval). Still, the purpose is clear enough for an agent to infer correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identify_dataset_geographyIdentify Dataset GeographyARead-onlyInspect
Free dataset-orchestration utility. Accepts bounded samples from plausible scalar columns and determines which column contains geography, then identifies its maintained reference system, country, and administrative level. The caller performs only structural parsing and sampling; it must not assign geographic meaning in advance. Returns up to three reviewable bindings at 60% confidence or better, plus a coordinate fallback when present; only an unambiguous result at 80% or better is recommended automatically. 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 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description carries most of the burden and does well: it discloses the 60%/80% confidence thresholds, the up-to-three binding cap, the coordinate fallback, and that no geometry is loaded or full dataset retained. Rate limits and exact output shape are still unstated.
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?
Reasonably dense but front-loads a vague 'Free dataset-orchestration utility' tag before the useful content, and the trailing 'No payment required' is filler. Several clauses could be tightened without losing meaning.
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?
There is no output schema, so the description must explain return values – and it partially does (up to three bindings at 60%, fallback, recommendation at 80%). But it never fully specifies the binding structure or how the coordinate fallback appears, leaving an agent unsure how to parse the response.
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 50%. The description reinforces the 'structural parsing and sampling' intent and the 'do not pre-label geographic system' constraint, which adds meaning over the schema. But two of four parameters (request_id, dataset_context) are undocumented and the description doesn't expand on country_scope or value-count 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 gives a specific verb+resource: it takes bounded scalar samples, finds the geography column, and identifies reference system, country, and admin level. It is distinct from the many siblings (identify_reference_system, check_geometry, etc.) though it never explicitly names or contrasts with them, leaving some overlap risk with identify_reference_system.
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 implies the calling context (caller does sampling, must not pre-label geography) but never states when to choose this over identify_reference_system or other siblings. No explicit when/when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identify_reference_systemIdentify Geographic Reference SystemARead-onlyInspect
Free geography utility. Checks a bounded sample of identifiers plus optional dataset/column context against maintained reference indexes and geometry banks. LLM clients must extract identifier values from the user's natural-language request and pass them as strings; do not put the prose question in the arguments, and preserve leading zeros. Use it when a caller is unsure which system or level their keys belong to. It returns one to three interpretations with confidence and preserves ambiguity until the user confirms one by retrying with expected.system. A caller who already knows the system can provide expected on the first call and receive a verified geography_binding directly. It does not convert the full dataset or return polygons. 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true. The description adds meaningful behavioral detail: it returns one to three interpretations with confidence, preserves ambiguity until the user confirms with expected.system, and can return a verified geography_binding directly. It also discloses that it is free and that it does not convert the full dataset or return polygons, going well beyond the minimal read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence earns its place: purpose, usage condition, client instruction, output behavior, exclusions, and cost. The core scoping statement is front-loaded. It is slightly dense, but no section feels redundant.
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 there is no output schema, the description compensates by summarizing the return behavior (1-3 interpretations with confidence, verified geography_binding) and the key boundaries (no full conversion, no polygons). It could elaborate more on dataset_context and validation_scope behavior, but the schema already covers those parameters in detail, so the overall picture is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the baseline is 3. The description adds important parameter semantics not present in the schema: LLM clients must extract identifier values from natural language, pass them as strings, preserve leading zeros, and not include the prose question. This materially helps an agent invoke identifier and identifiers correctly.
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+resource: 'Checks a bounded sample of identifiers ... against maintained reference indexes and geometry banks.' It also gives the exact scenario for use ('unsure which system or level their keys belong to') and explicitly distinguishes itself from conversion and geometry-returning tools, making it easy to separate from siblings such as convert_reference and 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?
The description explicitly says 'Use it when a caller is unsure which system or level their keys belong to' and describes an alternative path for callers who already know the system (provide expected.system). It also gives when-not guidance ('does not convert the full dataset or return polygons'), but it does not name the specific sibling tools that handle those cases, so it stops short of fully explicit alternatives.
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-onlyInspect
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. Current catalog: The same geography tools work worldwide across a cataloged baseline of 252 geographic entities, reaching up to Admin 2. Where additional country releases are available, the same calls automatically return deeper administrative tiers or maintained reference families. Additional detail is currently available for Australia, Brazil, Canada, France, Germany, Mexico, United Kingdom, United States.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description does not contradict this. It adds behavioral context by noting that shape-backed families use 'direct bbox-to-exact-shape lookup without crosswalks' and by describing the worldwide coverage baseline and country-specific deeper tiers. This goes beyond the annotation, providing useful insight into how the tool behaves across geographies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and usage, which is good. However, it includes a long 'Current catalog' paragraph that repeats boilerplate about coverage and country lists, which is tangential to direct tool invocation and could distract or be moved to get_catalog context. While not overly verbose, it contains non-essential content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description should specify the return value structure and any error/edge-case behavior. It does not describe the response format, whether it returns matching administrative tiers, point IDs, or other data. It also does not explain what happens when no match is found or when the shallow_loc_id is invalid. The description covers usage prerequisites well but leaves output behavior completely unaddressed, making it incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema: it clarifies that shallow_loc_id is 'the deepest canonical Admin 1-3 loc_id returned by resolve_point', points must be 'already known to fall within the supplied shallow_loc_id scope', and family defaults to administrative with examples like marine, postal_area, watershed. These additions help an agent understand parameter usage beyond raw field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('second-pass resolution') and resource (WGS84 coordinate or point array within a shallow_loc_id scope). It explicitly differentiates from resolve_point by requiring the shallow_loc_id returned by that first-pass tool, and references get_catalog for family selection. An agent can immediately understand what this tool does and how it differs from 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 implicitly provides usage guidance by framing the tool as a second-pass step: 'Supply one shared shallow_loc_id returned by resolve_point and one canonical family from get_catalog'. It also explains the family default and the special case of shape-backed families. However, it does not explicitly state when NOT to use this tool or contrast it with resolve_point beyond the second-pass implication, leaving some ambiguity for edge cases.
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-onlyInspect
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. Current catalog: The same geography tools work worldwide across a cataloged baseline of 252 geographic entities, reaching up to Admin 2. Where additional country releases are available, the same calls automatically return deeper administrative tiers or maintained reference families. Additional detail is currently available for Australia, Brazil, Canada, France, Germany, Mexico, United Kingdom, United States.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description adds valuable behavior beyond that: it does not open deep partitions or side-family shape banks, access limits depend on point count, and country releases automatically extend results. This gives the agent a clear behavioral model without contradicting the annotation.
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 first three sentences are tight and front-loaded, immediately establishing purpose, depth, and the handoff to resolve_deep_point. The final catalog paragraph is somewhat longer than strictly necessary, but it earns its place by clarifying expected depth and geographic coverage.
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 read-only reverse-geocoding tool with no output schema, the description explains what is returned, the maximum admin depth, the deeper-tool handoff, bulk behavior, access-limit basis, and current geographic coverage. An agent has enough context to select and invoke this tool correctly without consulting additional sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all seven parameters, including the lat/lon vs. points oneOf constraint, so the schema carries most of the parameter burden. The description adds only general context like 'bounded point array' and access limits based on point count, which is useful but does not deepen the meaning of specific parameters such as target_admin_level or include_marine_context.
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 operation ('first-pass reverse geocoding'), the resource ('one WGS84 coordinate or a bounded point array'), and the depth scope ('through Admin 3'). It explicitly contrasts itself with resolve_deep_point, so an agent can distinguish the sibling tools immediately.
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 use resolve_deep_point for Admin 4-6 or an explicit family, and it clarifies that single and bulk requests share the same contract. The catalog paragraph also explains when deeper tiers are automatically returned, removing ambiguity about worldwide vs. expanded country coverage.
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.
6 tool updates
- Removed
create_conversion_job - Removed
create_geometry_export - Removed
estimate_conversion_job - Removed
estimate_geometry_package - Removed
get_job_status - Removed
resolve_loc_id_scope
29 tool updates
- Removed
check_geometry - Changed
convert_reference9 fields changed- changed
Input schema / anyOfPrevious value: -[ - { - "required": [ - "from_system", - "value", - "to_system" - ] - }, - { - "required": [ - "items" - ] - } -]New value: +[ + { + "required": [ + "from_system", + "value" + ] + }, + { + "required": [ + "items" + ] + } +] - added
Input schema / properties / admin_level_hintAdded value: +{ + "description": "Optional admin-level hint for admin/name resolution.", + "maximum": 6, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / as_ofAdded value: +{ + "description": "ISO date or year used for time-bounded identities.", + "type": "string" +} - added
Input schema / properties / country_hintAdded value: +{ + "description": "Optional country hint for admin/name resolution.", + "type": "string" +} - added
Input schema / properties / items / items / properties / admin_level_hintAdded value: +{ + "description": "Optional admin-level hint for admin/name resolution.", + "maximum": 6, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / items / items / properties / as_ofAdded value: +{ + "description": "ISO date or year used for time-bounded identities.", + "type": "string" +} - added
Input schema / properties / items / items / properties / country_hintAdded value: +{ + "description": "Optional country hint for admin/name resolution.", + "type": "string" +} - added
Input schema / properties / to_system / defaultAdded value: +"daedalmap.loc_id" - changed
Input schema / properties / to_system / descriptionPrevious value: -"Output reference system, such as loc_id, zcta, nws_fire, overlay_nws_public_zone, overlay_tribal, admin_local, or admin_geometry."New value: +"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."
- Changed
estimate_conversion_job1 field changed- changed
Input schema / properties / batch_id / descriptionPrevious value: -"Coordinate mode only: batch id the resolve_points run will send."New value: +"Coordinate mode only: batch id the resolve_point run will send."
- Changed
get_catalog9 fields changed- added
Input schema / properties / catalogAdded value: +{ + "default": "data", + "description": "Catalog family. The geography facade defaults to geometry; other facades default to data.", + "enum": [ + "data", + "geometry" + ], + "type": "string" +} - added
Input schema / properties / country_scopeAdded value: +{ + "description": "Optional ISO3 focus for catalog='geometry' with detail='lite'.", + "type": "string" +} - added
Input schema / properties / detailAdded value: +{ + "default": "lite", + "description": "Use lite to select a pack, full for expanded metric/query inventories, or download for the complete raw catalog URL.", + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" +} - changed
Output schema / anyOfPrevious value: -[ - { - "required": [ - "packs" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "required": [ + "catalog", + "detail" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / catalogAdded value: +{ + "enum": [ + "data", + "geometry" + ], + "type": "string" +} - added
Output schema / properties / detailAdded value: +{ + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" +} - added
Output schema / properties / download_urlAdded value: +{ + "type": "string" +} - added
Output schema / properties / next_step / anyOfAdded value: +[ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } +] - removed
Output schema / properties / next_step / requiredRemoved value: -[ - "action" -]
- Added
get_data - Removed
get_disaster_link_chain - Removed
get_disaster_links_for_event - Removed
get_earthquake_events - Added
get_event - Removed
get_fx_rates - Changed
get_geometry7 fields changed- removed
Input schema / anyOfRemoved value: -[ - { - "required": [ - "loc_id" - ] - }, - { - "required": [ - "loc_ids" - ] - } -] - added
Input schema / oneOfAdded value: +[ + { + "required": [ + "loc_id" + ] + }, + { + "required": [ + "loc_ids" + ] + }, + { + "required": [ + "scope" + ] + } +] - removed
Input schema / properties / detailRemoved value: -{ - "default": "lite", - "description": "Lite returns shape metadata, bbox, and centroid. Full also includes the attached location-info block.", - "enum": [ - "lite", - "full" - ], - "type": "string" -} - changed
Input schema / properties / loc_ids / descriptionPrevious value: -"DaedalMap loc_ids to fetch in one call. Default public cap is deployment-configurable and lower when include_polygon is true."New value: +"Exact DaedalMap loc_ids to fetch in one call. Default public cap is deployment-configurable and lower when include_polygon is true." - added
Input schema / properties / loc_ids / minItemsAdded value: +1 - added
Input schema / properties / loc_ids / uniqueItemsAdded value: +true - added
Input schema / properties / scopeAdded value: +{ + "additionalProperties": false, + "properties": { + "admin_level": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ], + "description": "Descendant level to retrieve, such as admin_2, 2, or county." + }, + "bbox": { + "anyOf": [ + { + "items": { + "type": "number" + }, + "maxItems": 4, + "minItems": 4, + "type": "array" + }, + { + "type": "string" + } + ], + "description": "Optional minLon,minLat,maxLon,maxLat intersection filter." + }, + "parent_loc_id": { + "description": "Administrative parent loc_id, such as USA-TX or CAN-BC.", + "type": "string" + } + }, + "required": [ + "parent_loc_id", + "admin_level" + ], + "type": "object" +}
- Removed
get_live_earthquake_events - Removed
get_live_volcano_events - Added
get_loc_id_info - Changed
get_pack13 fields changed- added
Input schema / properties / catalogAdded value: +{ + "description": "Metadata family. When omitted, geometry facades default to geometry and known geometry-family ids are inferred; all other calls default to data.", + "enum": [ + "data", + "geometry" + ], + "type": "string" +} - added
Input schema / properties / country_scopeAdded value: +{ + "description": "Optional ISO3 country for a geometry family. Omit it to learn which countries publish the family; provide it for country-specific versions, vintages, levels, and artifacts.", + "pattern": "^[A-Za-z]{3}$", + "type": "string" +} - changed
Input schema / properties / detail / descriptionPrevious value: -"Use lite for normal discovery. Use full only for one selected pack when its complete public metadata is required."New value: +"Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file." - changed
Input schema / properties / detail / enumPrevious value: -[ - "lite", - "full" -]New value: +[ + "lite", + "full", + "download" +] - added
Input schema / properties / release_unitAdded value: +{ + "description": "Optional non-country geometry release unit such as GLOBAL or MARINE. Do not combine with country_scope.", + "pattern": "^[A-Za-z0-9_-]+$", + "type": "string" +} - changed
Output schema / anyOfPrevious value: -[ - { - "required": [ - "pack_id" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "required": [ + "catalog", + "pack_id", + "detail" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / catalogAdded value: +{ + "enum": [ + "data", + "geometry" + ], + "type": "string" +} - added
Output schema / properties / detailAdded value: +{ + "enum": [ + "lite", + "full", + "download" + ], + "type": "string" +} - added
Output schema / properties / download_callAdded value: +{ + "type": "object" +} - added
Output schema / properties / download_urlAdded value: +{ + "type": "string" +} - added
Output schema / properties / full_callAdded value: +{ + "type": "object" +} - added
Output schema / properties / next_step / anyOfAdded value: +[ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } +] - removed
Output schema / properties / next_step / requiredRemoved value: -[ - "action" -]
- Changed
get_tool_help7 fields changed- added
Input schema / oneOfAdded value: +[ + { + "not": { + "required": [ + "topic" + ] + }, + "required": [ + "tool_name" + ] + }, + { + "not": { + "required": [ + "tool_name" + ] + }, + "required": [ + "topic" + ] + } +] - added
Input schema / properties / questionAdded value: +{ + "description": "Optional question used only with a topic overview.", + "type": "string" +} - changed
Input schema / properties / tool_name / descriptionPrevious value: -"Exact tool name from tools/list."New value: +"Exact tool name from tools/list. Do not combine with topic." - added
Input schema / properties / topicAdded value: +{ + "description": "Workflow overview. Do not combine with tool_name.", + "enum": [ + "overview", + "data", + "disasters", + "custom_data", + "geometry" + ], + "type": "string" +} - removed
Input schema / requiredRemoved value: -[ - "tool_name" -] - added
Output schema / properties / next_step / anyOfAdded value: +[ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } +] - removed
Output schema / properties / next_step / requiredRemoved value: -[ - "action" -]
- Removed
get_tsunami_events - Removed
get_volcanic_activity - Removed
how_geometry_works - Removed
list_reference_systems - Removed
loc_id_info - Removed
query_dataset - Removed
read_geometry_catalog - Changed
resolve_deep_point4 fields changed- added
Input schema / oneOfAdded value: +[ + { + "not": { + "required": [ + "points" + ] + }, + "required": [ + "lat", + "lon" + ] + }, + { + "not": { + "anyOf": [ + { + "required": [ + "lat" + ] + }, + { + "required": [ + "lon" + ] + } + ] + }, + "required": [ + "points" + ] + } +] - added
Input schema / properties / batch_idAdded value: +{ + "description": "Optional caller-supplied batch id echoed for point arrays.", + "type": "string" +} - added
Input schema / properties / pointsAdded value: +{ + "description": "Points already known to fall within the supplied shallow_loc_id scope.", + "items": { + "additionalProperties": false, + "properties": { + "id": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ] + }, + "lat": { + "maximum": 90, + "minimum": -90, + "type": "number" + }, + "lon": { + "maximum": 180, + "minimum": -180, + "type": "number" + }, + "row_index": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ] + } + }, + "required": [ + "lat", + "lon" + ], + "type": "object" + }, + "minItems": 1, + "type": "array" +} - changed
Input schema / requiredPrevious value: -[ - "lat", - "lon", - "shallow_loc_id" -]New value: +[ + "shallow_loc_id" +]
- Removed
resolve_deep_points - Changed
resolve_point4 fields changed- added
Input schema / oneOfAdded value: +[ + { + "not": { + "required": [ + "points" + ] + }, + "required": [ + "lat", + "lon" + ] + }, + { + "not": { + "anyOf": [ + { + "required": [ + "lat" + ] + }, + { + "required": [ + "lon" + ] + } + ] + }, + "required": [ + "points" + ] + } +] - added
Input schema / properties / batch_idAdded value: +{ + "description": "Optional caller-supplied batch id echoed for point arrays.", + "type": "string" +} - added
Input schema / properties / pointsAdded value: +{ + "description": "Bounded WGS84 point array. Use top-level lat/lon instead for one point.", + "items": { + "additionalProperties": false, + "properties": { + "id": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ] + }, + "lat": { + "maximum": 90, + "minimum": -90, + "type": "number" + }, + "lon": { + "maximum": 180, + "minimum": -180, + "type": "number" + }, + "row_index": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ] + } + }, + "required": [ + "lat", + "lon" + ], + "type": "object" + }, + "minItems": 1, + "type": "array" +} - removed
Input schema / requiredRemoved value: -[ - "lat", - "lon" -]
- Removed
resolve_points - Removed
resolve_reference - Removed
search_disaster_links
5 tool updates
- Changed
estimate_conversion_job7 fields changed- changed
Input schema / anyOfPrevious value: -[ - { - "required": [ - "from_system", - "items" - ] - }, - { - "required": [ - "from_system", - "row_count" - ] - }, - { - "required": [ - "geography_binding", - "items" - ] - }, - { - "required": [ - "geography_binding", - "row_count" - ] - } -]New value: +[ + { + "required": [ + "from_system", + "items" + ] + }, + { + "required": [ + "from_system", + "row_count" + ] + }, + { + "required": [ + "geography_binding", + "items" + ] + }, + { + "required": [ + "geography_binding", + "row_count" + ] + }, + { + "required": [ + "geography_binding", + "point_count", + "request_id" + ] + } +] - added
Input schema / properties / batch_idAdded value: +{ + "description": "Coordinate mode only: batch id the resolve_points run will send.", + "type": "string" +} - changed
Input schema / properties / geography_binding / descriptionPrevious value: -"Known dataset-geography declaration. The estimate verifies it against distinct identifiers and avoids point containment."New value: +"Known dataset-geography declaration. Identifier modes require system; the estimate verifies it against distinct identifiers and avoids point containment. Mode coordinates quotes point resolution from point_count." - changed
Input schema / properties / geography_binding / properties / mode / enumPrevious value: -[ - "reference", - "loc_id" -]New value: +[ + "reference", + "loc_id", + "coordinates" +] - changed
Input schema / properties / geography_binding / properties / system / descriptionPrevious value: -"Declared identifier system. Used when from_system is omitted."New value: +"Declared identifier system. Used when from_system is omitted. Not used for mode coordinates." - removed
Input schema / properties / geography_binding / requiredRemoved value: -[ - "system" -] - added
Input schema / properties / point_countAdded value: +{ + "description": "Coordinate mode only: rows with a valid latitude/longitude pair. The quote ceiling; blank or invalid rows are excluded and never charged.", + "minimum": 0, + "type": "integer" +}
- Changed
get_geometry1 field changed- added
Input schema / properties / detailAdded value: +{ + "default": "lite", + "description": "Lite returns shape metadata, bbox, and centroid. Full also includes the attached location-info block.", + "enum": [ + "lite", + "full" + ], + "type": "string" +}
- Changed
get_pack1 field changed- added
Input schema / properties / detailAdded value: +{ + "default": "lite", + "description": "Use lite for normal discovery. Use full only for one selected pack when its complete public metadata is required.", + "enum": [ + "lite", + "full" + ], + "type": "string" +}
- Changed
list_reference_systems1 field changed- changed
Input schema / properties / include_crosswalks / descriptionPrevious value: -"Include actionable source-to-target crosswalk records. Default true."New value: +"Include actionable crosswalk and artifact records. Default false because these records are much larger than the system index."
- Changed
read_geometry_catalog1 field changed- changed
Input schema / properties / view / descriptionPrevious value: -"Catalog view to return. Use capabilities for the concise first-user coverage model. Default summary for compatibility."New value: +"Catalog view to return. Capabilities is the compact default and first-user coverage model. Public full returns the bulk-download location rather than embedding the raw catalog."
2 tool updates
- Changed
estimate_conversion_job1 field changed- changed
Input schema / properties / items / descriptionPrevious value: -"Sample or full rows; row-level fields may override top-level defaults."New value: +"Representative sample or full rows; the estimate resolves at most the first 32. Row-level fields may override top-level defaults."
- Changed
identify_reference_system1 field changed- changed
Input schema / properties / validation_scope / descriptionPrevious value: -"Describes whether the supplied identifiers are a sample or the complete distinct-key set. The tool validates every supplied identifier."New value: +"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."
3 tool updates
- Changed
read_geometry_catalog1 field changed- changed
Input schema / properties / country_scope / descriptionPrevious value: -"Optional ISO3 country code for view='capabilities'. Returns the selected country's baseline, active depth, families, and query guidance."New value: +"Optional ISO3 country code for view='capabilities'. Returns active depth, published families, and query guidance."
- Changed
resolve_deep_point5 fields changed- removed
Input schema / properties / admin_1_loc_idRemoved value: -{ - "description": "Exactly one Admin 1 loc_id from resolve_point, such as USA-CA.", - "minLength": 5, - "type": "string" -} - added
Input schema / properties / familyAdded value: +{ + "default": "administrative", + "description": "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.", + "pattern": "^[a-z0-9_]+$", + "type": "string" +} - removed
Input schema / properties / include_marine_contextRemoved value: -{ - "description": "Include parallel Marine overlaps. Defaults to true.", - "type": "boolean" -} - added
Input schema / properties / shallow_loc_idAdded value: +{ + "description": "The deepest canonical Admin 1-3 loc_id returned by resolve_point, such as USA-NY-061-009903.", + "minLength": 5, + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "lat", - "lon", - "admin_1_loc_id" -]New value: +[ + "lat", + "lon", + "shallow_loc_id" +]
- Changed
resolve_deep_points6 fields changed- removed
Input schema / properties / admin_1_loc_idRemoved value: -{ - "description": "Exactly one Admin 1 loc_id from resolve_points, such as USA-CA. All coordinates in the call must belong to it.", - "minLength": 5, - "type": "string" -} - added
Input schema / properties / familyAdded value: +{ + "default": "administrative", + "description": "One canonical family ID for the entire batch.", + "pattern": "^[a-z0-9_]+$", + "type": "string" +} - removed
Input schema / properties / include_marine_contextRemoved value: -{ - "description": "Include parallel Marine overlaps. Defaults to true.", - "type": "boolean" -} - changed
Input schema / properties / points / descriptionPrevious value: -"Points already known to fall within admin_1_loc_id. Maximum 100 per call during the initial technical rollout."New value: +"Points already known to fall within the supplied shallow_loc_id scope. Maximum 100 per call during the initial technical rollout." - added
Input schema / properties / shallow_loc_idAdded value: +{ + "description": "A canonical Admin 1-3 loc_id returned by resolve_points. All coordinates in the call must belong to its scope.", + "minLength": 5, + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "points", - "admin_1_loc_id" -]New value: +[ + "points", + "shallow_loc_id" +]
4 tool updates
- Added
resolve_deep_point - Added
resolve_deep_points - Changed
resolve_point10 fields changed- removed
Input schema / anyOfRemoved value: -[ - { - "required": [ - "lat", - "lon" - ] - }, - { - "required": [ - "points" - ] - } -] - removed
Input schema / properties / admin_1_scopeRemoved value: -{ - "description": "Required in deep mode. One Admin 1 loc_id returned by the standard pass, such as USA-CA. Every point must belong to this owner partition.", - "type": "string" -} - removed
Input schema / properties / batch_idRemoved value: -{ - "description": "Optional caller-supplied batch id echoed in the result.", - "type": "string" -} - removed
Input schema / properties / bulk_presetRemoved value: -{ - "description": "Cross-country standard-mode path that fixes the exact result level. Use instead of country_scope; target_admin_level may be omitted.", - "enum": [ - "global_admin_0", - "global_admin_1" - ], - "type": "string" -} - removed
Input schema / properties / country_hintRemoved value: -{ - "description": "Alias for country_scope for clients that already use hint terminology.", - "type": "string" -} - removed
Input schema / properties / country_scopeRemoved value: -{ - "description": "ISO3/Admin 0 loc_id scope such as USA or CAN. Optional in standard mode and required in deep mode; every deep-mode point must belong to this one country.", - "type": "string" -} - removed
Input schema / properties / lookup_modeRemoved value: -{ - "description": "Standard (default) caps I/O at Admin 3. Deep requires exactly one country_scope and one admin_1_scope, and opens at most one deep partition.", - "enum": [ - "standard", - "deep" - ], - "type": "string" -} - removed
Input schema / properties / pointsRemoved value: -{ - "description": "Points to resolve. Standard mode accepts cross-country batches and caps geometry I/O at Admin 3. Deep batches require one country_scope and one admin_1_scope; larger deep batches also require target_admin_level. Anonymous callers may receive a payment challenge; verified accounts have included throughput through 10,000 points.", - "items": { - "additionalProperties": false, - "properties": { - "id": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "string" - } - ], - "description": "Optional caller point identifier echoed in the result." - }, - "lat": { - "description": "Latitude in WGS84 decimal degrees.", - "maximum": 90, - "minimum": -90, - "type": "number" - }, - "lon": { - "description": "Longitude in WGS84 decimal degrees.", - "maximum": 180, - "minimum": -180, - "type": "number" - }, - "row_index": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "string" - } - ], - "description": "Optional caller row identifier echoed in the result." - } - }, - "required": [ - "lat", - "lon" - ], - "type": "object" - }, - "minItems": 1, - "type": "array" -} - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Optional exact requested level. Standard mode accepts Admin 0-3; deep mode accepts Admin 4-6. Omit it to return the deepest available level permitted by the selected mode."New value: +"Optional exact requested level from Admin 0-3. Omit it to return the deepest available shallow level." - added
Input schema / requiredAdded value: +[ + "lat", + "lon" +]
- Added
resolve_points
13 tool updates
- Changed
get_catalog1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "packs" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "catalog_version": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "generated_at": { + "type": [ + "string", + "null" + ] + }, + "guidance": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_count": { + "minimum": 0, + "type": "integer" + }, + "packs": { + "items": { + "type": "object" + }, + "type": "array" + }, + "provenance": { + "type": "object" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "tool_families": { + "items": { + "type": "object" + }, + "type": "array" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_disaster_link_chain1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "links", + "count", + "depth" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "chains": { + "items": { + "type": "object" + }, + "type": "array" + }, + "clarification": { + "type": "object" + }, + "count": { + "minimum": 0, + "type": "integer" + }, + "depth": { + "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" + }, + "event_id": { + "type": "string" + }, + "guidance": { + "type": "object" + }, + "links": { + "items": { + "type": "object" + }, + "type": "array" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "provenance": { + "type": "object" + }, + "query_event_id": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "related": { + "items": { + "type": "object" + }, + "type": "array" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "resolved_event": { + "type": "object" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_disaster_links_for_event1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "event_id", + "related", + "count" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "chains": { + "items": { + "type": "object" + }, + "type": "array" + }, + "clarification": { + "type": "object" + }, + "count": { + "minimum": 0, + "type": "integer" + }, + "depth": { + "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" + }, + "event_id": { + "type": "string" + }, + "guidance": { + "type": "object" + }, + "links": { + "items": { + "type": "object" + }, + "type": "array" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "provenance": { + "type": "object" + }, + "query_event_id": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "related": { + "items": { + "type": "object" + }, + "type": "array" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "resolved_event": { + "type": "object" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_earthquake_events1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "source_id", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "capability_id": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "filters_applied": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "limit": { + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "query_mode": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "rows": { + "items": { + "type": "object" + }, + "type": "array" + }, + "sort": { + "type": "array" + }, + "source_id": { + "type": "string" + }, + "truncated": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_fx_rates1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "source_id", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "capability_id": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "filters_applied": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "limit": { + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "query_mode": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "rows": { + "items": { + "type": "object" + }, + "type": "array" + }, + "sort": { + "type": "array" + }, + "source_id": { + "type": "string" + }, + "truncated": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_live_earthquake_events1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "source_id", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "capability_id": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "filters_applied": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "limit": { + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "query_mode": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "rows": { + "items": { + "type": "object" + }, + "type": "array" + }, + "sort": { + "type": "array" + }, + "source_id": { + "type": "string" + }, + "truncated": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_live_volcano_events1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "source_id", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "capability_id": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "filters_applied": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "limit": { + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "query_mode": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "rows": { + "items": { + "type": "object" + }, + "type": "array" + }, + "sort": { + "type": "array" + }, + "source_id": { + "type": "string" + }, + "truncated": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_pack1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "pack_id" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "guidance": { + "type": "object" + }, + "material_policy": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "sources": { + "items": { + "type": "object" + }, + "type": "array" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_tool_help1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "tool_name" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "access": { + "type": "object" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "examples": { + "type": "array" + }, + "guidance": { + "type": "object" + }, + "important_output_fields": { + "type": "array" + }, + "input_schema": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "provenance": { + "type": "object" + }, + "purpose": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "recommended_next_calls": { + "type": "array" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "tool_name": { + "type": "string" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_tsunami_events1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "source_id", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "capability_id": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "filters_applied": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "limit": { + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "query_mode": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "rows": { + "items": { + "type": "object" + }, + "type": "array" + }, + "sort": { + "type": "array" + }, + "source_id": { + "type": "string" + }, + "truncated": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_volcanic_activity1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "source_id", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "capability_id": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "filters_applied": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "limit": { + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "query_mode": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "rows": { + "items": { + "type": "object" + }, + "type": "array" + }, + "sort": { + "type": "array" + }, + "source_id": { + "type": "string" + }, + "truncated": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
query_dataset1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "source_id", + "row_count", + "rows" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "capability_id": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "filters_applied": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "limit": { + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "query_mode": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "row_count": { + "minimum": 0, + "type": "integer" + }, + "rows": { + "items": { + "type": "object" + }, + "type": "array" + }, + "sort": { + "type": "array" + }, + "source_id": { + "type": "string" + }, + "truncated": { + "type": "boolean" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
search_disaster_links1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "chains", + "count" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "chains": { + "items": { + "type": "object" + }, + "type": "array" + }, + "clarification": { + "type": "object" + }, + "count": { + "minimum": 0, + "type": "integer" + }, + "depth": { + "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" + }, + "event_id": { + "type": "string" + }, + "guidance": { + "type": "object" + }, + "links": { + "items": { + "type": "object" + }, + "type": "array" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "provenance": { + "type": "object" + }, + "query_event_id": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "related": { + "items": { + "type": "object" + }, + "type": "array" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "resolved_event": { + "type": "object" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
1 tool update
- Changed
resolve_point7 fields changed- added
Input schema / properties / admin_1_scopeAdded value: +{ + "description": "Required in deep mode. One Admin 1 loc_id returned by the standard pass, such as USA-CA. Every point must belong to this owner partition.", + "type": "string" +} - changed
Input schema / properties / bulk_preset / descriptionPrevious value: -"Cross-country fast path that fixes the result level to admin_0 or admin_1. Use instead of country_scope; target_admin_level may be omitted."New value: +"Cross-country standard-mode path that fixes the exact result level. Use instead of country_scope; target_admin_level may be omitted." - changed
Input schema / properties / country_scope / descriptionPrevious value: -"ISO3/admin_0 loc_id scope such as USA or CAN. Optional for up to 100 exploratory points and required for larger batches; every point must belong to this one country."New value: +"ISO3/Admin 0 loc_id scope such as USA or CAN. Optional in standard mode and required in deep mode; every deep-mode point must belong to this one country." - added
Input schema / properties / include_marine_contextAdded value: +{ + "description": "Include parallel Marine overlaps for land matches. Defaults to true; set false for fast administrative loc_id previews. Offshore Marine fallback still applies.", + "type": "boolean" +} - added
Input schema / properties / lookup_modeAdded value: +{ + "description": "Standard (default) caps I/O at Admin 3. Deep requires exactly one country_scope and one admin_1_scope, and opens at most one deep partition.", + "enum": [ + "standard", + "deep" + ], + "type": "string" +} - changed
Input schema / properties / points / descriptionPrevious value: -"Points to resolve. Up to 25 may be exploratory. Above 25, country_scope and target_admin_level are required. Anonymous callers receive a payment challenge; verified accounts have included throughput through 10,000 points."New value: +"Points to resolve. Standard mode accepts cross-country batches and caps geometry I/O at Admin 3. Deep batches require one country_scope and one admin_1_scope; larger deep batches also require target_admin_level. Anonymous callers may receive a payment challenge; verified accounts have included throughput through 10,000 points." - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Stopping level such as admin_0 through admin_5. Optional for up to 100 exploratory points and required for larger batches."New value: +"Optional exact requested level. Standard mode accepts Admin 0-3; deep mode accepts Admin 4-6. Omit it to return the deepest available level permitted by the selected mode."
2 tool updates
- Added
identify_dataset_geography - Changed
resolve_reference1 field changed- changed
Input schema / properties / iso3 / descriptionPrevious value: -"Country hint for system-specific crosswalks. Default USA."New value: +"Optional country hint for system-specific crosswalks. Omit for a globally scoped identifier system."
1 tool update
- Changed
identify_reference_system2 fields changed- added
Input schema / properties / dataset_contextAdded value: +{ + "additionalProperties": false, + "description": "Bounded, non-row dataset clues used to rank plausible interpretations without replacing exact identifier verification.", + "properties": { + "column_name": { + "type": "string" + }, + "column_names": { + "items": { + "type": "string" + }, + "maxItems": 1000, + "type": "array" + }, + "file_name": { + "type": "string" + }, + "local_format_match_rate": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "row_geography": { + "description": "Optional plain-language clue such as county, tract, or ZIP area.", + "type": "string" + }, + "sheet_name": { + "type": "string" + } + }, + "type": "object" +} - changed
Input schema / properties / expected / properties / system / descriptionPrevious value: -"Expected reference system, such as us_census_geoid, loc_id, zcta, or a catalog reference system."New value: +"Caller-declared reference system, such as us_census_geoid, loc_id, zcta, or a catalog reference system. Supply it immediately when known, or after choosing an identification result."
8 tool updates
- Changed
convert_reference6 fields changed- removed
Input schema / properties / bridge_vintageRemoved value: -{ - "description": "Optional source bridge vintage to require.", - "type": "string" -} - changed
Input schema / properties / iso3 / descriptionPrevious value: -"Country hint for bridge artifacts. Default USA."New value: +"Country hint for crosswalk artifacts. Default USA." - removed
Input schema / properties / items / items / properties / bridge_vintageRemoved value: -{ - "description": "Optional bridge vintage for this row.", - "type": "string" -} - added
Input schema / properties / items / items / properties / relationship_vintageAdded value: +{ + "description": "Optional relationship vintage for this row.", + "type": "string" +} - added
Input schema / properties / relationship_vintageAdded value: +{ + "description": "Optional source relationship vintage to require.", + "type": "string" +} - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Admin level used as the intermediate bridge target. Default admin_2."New value: +"Admin level used as the intermediate crosswalk target. Default admin_2."
- Changed
create_conversion_job4 fields changed- removed
Input schema / properties / bridge_vintageRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / items / items / properties / bridge_vintageRemoved value: -{ - "type": "string" -} - added
Input schema / properties / items / items / properties / relationship_vintageAdded value: +{ + "type": "string" +} - added
Input schema / properties / relationship_vintageAdded value: +{ + "type": "string" +}
- Changed
estimate_conversion_job4 fields changed- removed
Input schema / properties / bridge_vintageRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / items / items / properties / bridge_vintageRemoved value: -{ - "type": "string" -} - added
Input schema / properties / items / items / properties / relationship_vintageAdded value: +{ + "type": "string" +} - added
Input schema / properties / relationship_vintageAdded value: +{ + "type": "string" +}
- Changed
list_reference_systems3 fields changed- added
Input schema / properties / country_scopeAdded value: +{ + "description": "Optional ISO3 country filter. Use this for a focused country capability answer.", + "type": "string" +} - added
Input schema / properties / include_crosswalksAdded value: +{ + "description": "Include actionable source-to-target crosswalk records. Default true.", + "type": "boolean" +} - added
Input schema / properties / read_wipAdded value: +{ + "description": "Local loopback MCP only. Include staged or non-callable preprocessing records for operator review. Default false.", + "type": "boolean" +}
- Changed
loc_id_info2 fields changed- changed
Input schema / properties / iso3 / descriptionPrevious value: -"Optional country hint for bridge artifacts. Defaults to the loc_id country when possible."New value: +"Optional country hint for crosswalk artifacts. Defaults to the loc_id country when possible." - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Admin level for bridge-backed reverse reference lookup. Inferred when omitted."New value: +"Admin level for crosswalk-backed reverse reference lookup. Inferred when omitted."
- Changed
read_geometry_catalog1 field changed- changed
Input schema / properties / view / enumPrevious value: -[ - "capabilities", - "summary", - "countries", - "admin_coverage", - "bridges", - "products", - "named_reference_objects", - "full" -]New value: +[ + "capabilities", + "summary", + "countries", + "admin_coverage", + "crosswalk_artifacts", + "crosswalks", + "products", + "named_reference_objects", + "full" +]
- Changed
resolve_point2 fields changed- changed
Input schema / properties / country_scope / descriptionPrevious value: -"ISO3/admin_0 loc_id scope such as USA or CAN. Optional for up to 25 exploratory points and required for larger batches; every point must belong to this one country."New value: +"ISO3/admin_0 loc_id scope such as USA or CAN. Optional for up to 100 exploratory points and required for larger batches; every point must belong to this one country." - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Stopping level such as admin_0 through admin_5. Optional for up to 25 exploratory points and required for larger batches."New value: +"Stopping level such as admin_0 through admin_5. Optional for up to 100 exploratory points and required for larger batches."
- Changed
resolve_reference6 fields changed- removed
Input schema / properties / bridge_vintageRemoved value: -{ - "description": "Optional bridge vintage to require, such as usa_geometry_current or census_2020_relationship_files.", - "type": "string" -} - changed
Input schema / properties / iso3 / descriptionPrevious value: -"Country hint for system-specific bridges. Default USA."New value: +"Country hint for system-specific crosswalks. Default USA." - removed
Input schema / properties / items / items / properties / bridge_vintageRemoved value: -{ - "description": "Optional bridge vintage for this row.", - "type": "string" -} - added
Input schema / properties / items / items / properties / relationship_vintageAdded value: +{ + "description": "Optional relationship vintage for this row.", + "type": "string" +} - added
Input schema / properties / relationship_vintageAdded value: +{ + "description": "Optional relationship vintage to require, such as usa_geometry_current or census_2020_relationship_files.", + "type": "string" +} - changed
Input schema / properties / target_admin_level / descriptionPrevious value: -"Admin target level for bridge-backed resolution. Default admin_2. Accepts admin_0..admin_5, 0..5, or names such as country, state, county, tract, block_group, or block."New value: +"Admin target level for crosswalk-backed resolution. Default admin_2. Accepts admin_0..admin_5, 0..5, or names such as country, state, county, tract, block_group, or block."
3 tool updates
- Changed
get_pack1 field changed- changed
Input schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."New value: +"Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change."
- Changed
query_dataset1 field changed- changed
Input schema / properties / pack_id / descriptionPrevious value: -"Pack identifier such as 'currency', 'earthquakes', 'floods', 'hurricanes', 'tornadoes', 'tsunamis', 'un_sdg', 'volcanoes', 'world_factbook', or 'worldpop'."New value: +"Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change."
- Changed
read_geometry_catalog3 fields changed- added
Input schema / properties / country_scopeAdded value: +{ + "description": "Optional ISO3 country code for view='capabilities'. Returns the selected country's baseline, active depth, families, and query guidance.", + "type": "string" +} - added
Input schema / properties / read_wipAdded value: +{ + "description": "Local loopback MCP only. When true, reads the internal geometry catalog projection, including staged and in-progress records. Hosted/public MCP requests are denied. Default false.", + "type": "boolean" +} - changed
Input schema / properties / view / enumPrevious value: -[ - "capabilities", - "summary", - "admin_coverage", - "bridges", - "products", - "named_reference_objects", - "full" -]New value: +[ + "capabilities", + "summary", + "countries", + "admin_coverage", + "bridges", + "products", + "named_reference_objects", + "full" +]
1 tool update
- Changed
read_geometry_catalog2 fields changed- changed
Input schema / properties / view / descriptionPrevious value: -"Catalog view to return. Default summary."New value: +"Catalog view to return. Use capabilities for the concise first-user coverage model. Default summary for compatibility." - changed
Input schema / properties / view / enumPrevious value: -[ - "summary", - "admin_coverage", - "bridges", - "products", - "named_reference_objects", - "full" -]New value: +[ + "capabilities", + "summary", + "admin_coverage", + "bridges", + "products", + "named_reference_objects", + "full" +]
7 tool updates
- Changed
create_conversion_job14 fields changed- changed
Input schema / additionalPropertiesPrevious value: -trueNew value: +false - added
Input schema / anyOfAdded value: +[ + { + "required": [ + "from_system" + ] + }, + { + "required": [ + "geography_binding" + ] + } +] - added
Input schema / properties / bridge_vintageAdded value: +{ + "type": "string" +} - added
Input schema / properties / geography_bindingAdded value: +{ + "additionalProperties": false, + "properties": { + "country_scope": { + "type": "string" + }, + "geo_level": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "id_column": { + "type": "string" + }, + "mode": { + "enum": [ + "reference", + "loc_id" + ], + "type": "string" + }, + "system": { + "type": "string" + }, + "vintage": { + "type": "string" + } + }, + "required": [ + "system" + ], + "type": "object" +} - added
Input schema / properties / iso3Added value: +{ + "type": "string" +} - changed
Input schema / properties / items / descriptionPrevious value: -"Rows to convert; each row needs value and may include row_index."New value: +"Rows to convert; row-level fields may override top-level defaults." - added
Input schema / properties / items / items / additionalPropertiesAdded value: +false - added
Input schema / properties / items / items / propertiesAdded value: +{ + "bridge_vintage": { + "type": "string" + }, + "data": { + "additionalProperties": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "integer" + }, + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "description": "Original spreadsheet columns to preserve. Column names beginning daedalmap_ are reserved for generated output fields.", + "maxProperties": 200, + "type": "object" + }, + "from_system": { + "type": "string" + }, + "id": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ] + }, + "iso3": { + "type": "string" + }, + "limit": { + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "min_share": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "row_index": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ] + }, + "target_admin_level": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "to_system": { + "type": "string" + }, + "value": { + "description": "Identifier value; keep as a string to preserve leading zeros.", + "type": "string" + } +} - added
Input schema / properties / items / items / requiredAdded value: +[ + "value" +] - added
Input schema / properties / limitAdded value: +{ + "maximum": 100, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / min_shareAdded value: +{ + "maximum": 1, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / output_formatAdded value: +{ + "enum": [ + "json_rows", + "csv", + "jsonl", + "parquet" + ], + "type": "string" +} - added
Input schema / properties / output_nameAdded value: +{ + "maxLength": 80, + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "from_system", - "items" -]New value: +[ + "items" +]
- Changed
create_geometry_export3 fields changed- added
Input schema / properties / format / enumAdded value: +[ + "geojson", + "geojson_gzip", + "zip" +] - added
Input schema / properties / loc_ids / descriptionAdded value: +"Selected loc_ids. The default synchronous limit is 250; larger calls return a typed operational-limit response." - added
Input schema / properties / output_nameAdded value: +{ + "maxLength": 80, + "type": "string" +}
- Changed
estimate_conversion_job13 fields changed- changed
Input schema / additionalPropertiesPrevious value: -trueNew value: +false - changed
Input schema / anyOfPrevious value: -[ - { - "required": [ - "from_system", - "items" - ] - }, - { - "required": [ - "from_system", - "row_count" - ] - } -]New value: +[ + { + "required": [ + "from_system", + "items" + ] + }, + { + "required": [ + "from_system", + "row_count" + ] + }, + { + "required": [ + "geography_binding", + "items" + ] + }, + { + "required": [ + "geography_binding", + "row_count" + ] + } +] - added
Input schema / properties / bridge_vintageAdded value: +{ + "type": "string" +} - added
Input schema / properties / geography_bindingAdded value: +{ + "additionalProperties": false, + "description": "Known dataset-geography declaration. The estimate verifies it against distinct identifiers and avoids point containment.", + "properties": { + "country_scope": { + "type": "string" + }, + "geo_level": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "id_column": { + "description": "Identifier-column name for future artifact inputs; inline items continue to use value.", + "type": "string" + }, + "mode": { + "enum": [ + "reference", + "loc_id" + ], + "type": "string" + }, + "system": { + "description": "Declared identifier system. Used when from_system is omitted.", + "type": "string" + }, + "vintage": { + "type": "string" + } + }, + "required": [ + "system" + ], + "type": "object" +} - added
Input schema / properties / iso3Added value: +{ + "type": "string" +} - changed
Input schema / properties / items / descriptionPrevious value: -"Sample or full rows with at least value; row-level systems may override top-level systems."New value: +"Sample or full rows; row-level fields may override top-level defaults." - added
Input schema / properties / items / items / additionalPropertiesAdded value: +false - added
Input schema / properties / items / items / propertiesAdded value: +{ + "bridge_vintage": { + "type": "string" + }, + "data": { + "additionalProperties": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + }, + { + "type": "integer" + }, + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "description": "Original spreadsheet columns to preserve. Column names beginning daedalmap_ are reserved for generated output fields.", + "maxProperties": 200, + "type": "object" + }, + "from_system": { + "type": "string" + }, + "id": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ] + }, + "iso3": { + "type": "string" + }, + "limit": { + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "min_share": { + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "row_index": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + } + ] + }, + "target_admin_level": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "to_system": { + "type": "string" + }, + "value": { + "description": "Identifier value; keep as a string to preserve leading zeros.", + "type": "string" + } +} - added
Input schema / properties / items / items / requiredAdded value: +[ + "value" +] - added
Input schema / properties / limitAdded value: +{ + "maximum": 100, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / min_shareAdded value: +{ + "maximum": 1, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / output_formatAdded value: +{ + "description": "Enriched-row output format. CSV is spreadsheet-friendly; Parquet is compact and typed; JSON Lines is stream-friendly.", + "enum": [ + "json_rows", + "csv", + "jsonl", + "parquet" + ], + "type": "string" +} - added
Input schema / properties / output_nameAdded value: +{ + "description": "Optional safe base filename.", + "maxLength": 80, + "type": "string" +}
- Changed
estimate_geometry_package3 fields changed- changed
Input schema / properties / format / descriptionPrevious value: -"Requested delivery format: geojson, geojson_gzip, zip, geoparquet, flatgeobuf, or pmtiles."New value: +"Implemented delivery format. Unsupported format names are rejected rather than silently returning another representation." - added
Input schema / properties / format / enumAdded value: +[ + "geojson", + "geojson_gzip", + "zip" +] - added
Input schema / properties / output_nameAdded value: +{ + "description": "Optional safe base filename for the export.", + "maxLength": 80, + "type": "string" +}
- Added
how_geometry_works - Added
identify_reference_system - Changed
resolve_reference1 field changed- changed
Input schema / properties / from_system / descriptionPrevious value: -"Input reference system, such as loc_id, admin_boundary, zip, zcta, overlay_zcta, nws_zone, nws_fire, overlay_nws_fire_weather_zone, tribal, water_body, marine_eez, nuts, historical_country/iso3166_3, or a catalog family id."New value: +"Input reference system, such as loc_id, census_geoid/us_census_geoid, admin_boundary, zip, zcta, overlay_zcta, nws_zone, nws_fire, overlay_nws_fire_weather_zone, tribal, water_body, marine_eez, nuts, historical_country/iso3166_3, or a catalog family id."
Related MCP Connectors
- earthOAuthcom.mireye
MCP server for Mireye Earth — federal-source-cited geospatial data for any MCP-aware agent.
Geo-based flight search MCP server. Find more flights between any two places on earth
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
MCP server for Japan geodata: cadastral lot numbers (chiban) and reverse geocoding, for AI agents.
Related MCP Servers
AlicenseAqualityBmaintenanceAn MCP server for querying the FDSN Web Service Event APIs of multiple seismological datacenters and retrieving earthquake information as JSON.61AGPL 3.0- AlicenseAqualityCmaintenanceMCP server wrapping the USGS Earthquake Hazards API, enabling AI assistants to search the global earthquake catalog, look up event details, count quakes, find 'Did You Feel It' reports, and read realtime feeds.5MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that makes live Earth data usable by AI agents. Its initial data sources cover natural hazards: earthquakes from the USGS FDSN event catalog and volcanic activity from the Smithsonian Global Volcanism Program.MIT
- AlicenseNot gradedqualityDmaintenanceA powerful MCP server that connects AI assistants to authoritative natural hazard data sources, enabling monitoring of earthquakes, tsunamis, volcanoes, and solar events with configurable alerts and webhooks.22 PyPI1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.