DaedalMap Geography Tools (loc_id)
Server Details
Resolve coordinates and geographic identifiers to loc_id, crosswalks, and bounded shapes.
- Status
- Healthy
- Uptime
- 95.8% over 46 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 11 tools
Most tools are clearly delineated, and descriptions explicitly cross-reference near-neighbors (e.g. get_geometry vs get_loc_id_info, resolve_point vs resolve_deep_point). However, there is a cluster of three reference-related tools (convert_reference, identify_reference_system, identify_dataset_geography) whose boundaries, while spelled out, could still trip up an agent about which to invoke first, and the catalog/pack/help trio requires careful reading.
Every tool follows a clean verb_noun snake_case pattern (compare_geographies, get_catalog, get_geometry, get_loc_id_info, identify_reference_system, resolve_point). No mixing of conventions or vague standalone verbs.
Eleven tools is well-scoped for a geographic identity/resolution service, with each tool covering a distinct stage (discovery, identification, conversion, resolution, geometry, comparison, meta-help). No obvious redundancy or bloat.
The surface covers discovery, reference identification/conversion, shallow/deep point resolution, geometry retrieval, place info, comparison, and help—a fairly complete lifecycle for a read-only geography service. Minor gap: no explicit bulk crosswalk export or forward-geocoding (address-to-coordinate) operation, though these may be out of scope.
Available Tools
11 toolscompare_geographiesCompare Geographic IdentitiesARead-onlyIdempotentInspect
Compare two geographic identities for the public guarantees implemented today: containment/common ancestry and temporal validity for the requested vintages. The response may include additional maintained evidence, but callers must not rely on deeper topology or relationship semantics as a stable contract until that review is complete. Use convert_reference first for names or outside identifiers. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ISO date or year applied to both identities. | |
| items | No | Bounded geography pairs to compare in one call. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| left_as_of | No | Optional ISO date or year for the left identity; overrides as_of. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| left_loc_id | No | First DaedalMap loc_id. | |
| right_as_of | No | Optional ISO date or year for the right identity; overrides as_of. | |
| right_loc_id | No | Second DaedalMap loc_id. | |
| include_successors | No | Include direct successors and present-day descendants for maintained historical identities. Default true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| reason | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| item_count | No | |
| request_id | No | |
| failed_count | No | |
| clarification | No | |
| meter_receipt | No | |
| compared_count | No | |
| spatial_relation | No | |
| temporal_relation | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description warns that the response may include additional maintained evidence and that deeper topology or relationship semantics are not a stable contract. This is valuable non-obvious behavioral context that an agent needs before trusting the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: the core purpose is front-loaded, the stability caveat is stated, and the prerequisite routing is given. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema, and annotations, the description covers the essential behavioral contract, the supported comparison semantics, and the prerequisite conversion step. Nothing critical is missing for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds general context like 'requested vintages' and 'names or outside identifiers', but it does not materially deepen parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Compare') and resource ('two geographic identities') and enumerates the exact guarantees covered: containment/common ancestry and temporal validity. It is clearly distinct from the get_* sibling tools and even routes name/identifier resolution to convert_reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs callers to use convert_reference first for names or outside identifiers, which is a concrete alternative and sequencing rule. It also sets expectations about what callers may rely on, effectively saying when this tool is appropriate and when deeper semantics should not be assumed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_referenceConvert Geographic ReferenceARead-onlyIdempotentInspect
The single geographic reference converter. Converts one reference, or a bounded list, through DaedalMap loc_id: X -> loc_id -> Y. Omit to_system to enter the loc_id universe; provide it for any-to-any conversion. Use get_pack first when the family or country-specific system is unknown. The tools/list access metadata states the current free, account, and paid item allowances; exceeding an included allowance requires payment and exceeding the paid ceiling returns a typed cap error.
| Name | Required | Description | Default |
|---|---|---|---|
| iso3 | No | Country hint for crosswalk artifacts. Default USA. | |
| as_of | No | ISO date or year used for time-bounded identities. | |
| items | No | Reference conversions to run in one call. Default public cap is deployment-configurable. | |
| limit | No | Maximum ranked output references to return. Default 10. | |
| value | No | Identifier or name in the input system. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| min_share | No | Optional minimum overlap share threshold. | |
| to_system | No | Optional output reference system. Defaults to DaedalMap loc_id; provide zcta, nws_fire, overlay_nws_public_zone, overlay_tribal, admin_local, or another catalog system for any-to-any conversion. | daedalmap.loc_id |
| request_id | No | Optional caller-supplied request id for tracing. | |
| from_system | No | Input reference system, such as zip, overlay_zcta, nws_fire, tribal, admin_boundary, or loc_id. | |
| country_hint | No | Optional country hint for admin/name resolution. | |
| admin_level_hint | No | Optional admin-level hint for admin/name resolution. | |
| target_admin_level | No | Admin level used as the intermediate crosswalk target. Default admin_2. | |
| relationship_vintage | No | Optional source relationship vintage to require. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| from | No | |
| error | No | |
| loc_id | No | |
| reason | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| to_system | No | |
| item_count | No | |
| request_id | No | |
| from_system | No | |
| clarification | No | |
| meter_receipt | No | |
| converted_count | No | |
| unconverted_count | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the description's added value is the allowance/payment/cap-error model. It discloses that exceeding included allowances requires payment and that exceeding the paid ceiling returns a typed cap error, which is useful operational context beyond the annotations. It does not directly state how to discover current allowances, only points to tools/list metadata.
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 purpose and then packs usage, prerequisite, and cost behavior into a few sentences. It is dense but not padded; the DaedalMap notation and meta reference to tools/list access metadata keep it from being maximally crisp.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich schema (100% description coverage) and an output schema, the description focuses on the non-schema gaps: conversion modes, get_pack prerequisite, and cap/payment behavior. Given the annotations and output schema, this is complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic context for the to_system parameter, explaining omission versus provision, and distinguishes single-reference from bounded-list input modes, going beyond the schema's field-level documentation. Most per-parameter details remain in the schema, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'The single geographic reference converter' and describes conversion through DaedalMap loc_id, making the verb and resource clear. It also differentiates from the sibling get_pack by naming when to use that tool first. Jargon like 'X -> loc_id -> Y' is dense but does not obscure the core purpose.
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?
Gives explicit conditional usage: 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. These are concrete when-to-use and prerequisite rules rather than implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_catalogList Available Packs and Geometry FamiliesARead-onlyIdempotentInspect
Discover data packs or geometry families progressively: lite selection, full metric/query inventory, or a raw catalog download URL. Choose one result and call get_pack next. Current catalog: The same geography tools work worldwide across a cataloged baseline of 252 geographic entities, reaching up to Admin 2. Where additional country releases are available, the same calls automatically return deeper administrative tiers or maintained reference families. Additional detail is currently available for Australia, Brazil, Canada, France, Germany, Mexico, United Kingdom, United States.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Use lite to select a pack, full for expanded metric/query inventories, or download for the complete raw catalog URL. | lite |
| loc_id | No | Optional DaedalMap loc_id for catalog='data'. Combine with time_range to discover packs confirmed for both place and time. For place details without pack filtering, use get_loc_id_info. | |
| catalog | No | Catalog family. The geography facade defaults to geometry; other facades default to data. | data |
| time_range | No | Optional inclusive discovery window for catalog='data'. At least one bound is required. | |
| country_scope | No | Optional ISO3 focus for catalog='geometry' with detail='lite'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| packs | No | |
| detail | No | |
| reason | No | |
| catalog | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| pack_count | No | |
| provenance | No | |
| request_id | No | |
| download_url | No | |
| generated_at | No | |
| clarification | No | |
| tool_families | No | |
| catalog_version | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description doesn't repeat those. It adds valuable behavioral context: the tool automatically returns deeper administrative tiers for certain countries, and the progressive discovery behavior. This goes beyond annotations and helps the agent understand the tool's adaptive output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is efficient and front-loaded, stating the core function and the three discovery levels. The second sentence gives workflow guidance. The second paragraph adds catalog scope context, which is useful but slightly verbose. Overall, it's well-structured and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 optional parameters, nested object, enums) and the presence of an output schema, the description is complete. It explains the catalog's geographic scope and the progressive workflow, which the schema does not. It doesn't need to cover return values because the output schema exists. The description provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has clear documentation. The main description doesn't add parameter-specific semantics beyond the workflow context (e.g., progressive detail levels), which the schema already explains. This meets the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to discover data packs or geometry families with progressive levels (lite, full, download). It distinguishes itself from get_pack by explicitly routing the agent to call get_pack next, and from get_data by focusing on catalog listing rather than data retrieval. The verb 'discover' and resource 'catalog' are specific.
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 clear workflow: start with lite to select a pack, then call get_pack. It also mentions that get_loc_id_info is the alternative for place details without pack filtering (in the parameter description). However, it doesn't explicitly state when not to use this tool versus get_data or get_tool_help, though the workflow implication is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_geometryRetrieve Shapes for Known loc_idsARead-onlyIdempotentInspect
Shape availability and bounded coordinate retrieval only: use when you already have exact loc_ids, or one administrative parent_loc_id plus target admin_level. The default fast preflight returns has_shape, shape metadata, centroid, and bounding box; set include_polygon=true only for GeoJSON coordinates. Use get_loc_id_info for hierarchy, identity, catalog coverage, or crosswalk facts; get_geometry does not return those place details. Administrative scope queries stay within the optimized Admin Spine layout, while independent geometry families require exact loc_ids. Historical geometry is returned first and successors are never substituted automatically. Access is selected-material dependent: tools/list metadata gives the lane ceilings, while the chosen geometry bank decides whether payment is required.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| loc_id | No | DaedalMap loc_id, such as USA-CA-037, USA-Z-00601, USA-NWSFZ-AKZ317, EEZ-USA, or IHO1953-240001002. | |
| loc_ids | No | Exact DaedalMap loc_ids to fetch in one call. Default public cap is deployment-configurable and lower when include_polygon is true. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| include_polygon | No | When true, include the full GeoJSON geometry. Default false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| items | No | |
| scope | No | |
| reason | No | |
| missing | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| available | No | |
| next_step | No | |
| requested | No | |
| selection | No | |
| request_id | No | |
| clarification | No | |
| meter_receipt | No | |
| include_polygon | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly/idempotent/non-destructive), and the description adds real behavior: default preflight payload contents, that include_polygon is only for GeoJSON, historical-first with no automatic successor substitution, and an access/payment gate. The access sentence is useful but cryptically worded ('selected-material dependent', 'lane ceilings'), which blunts otherwise strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in sentence one, but the remaining text is dense internal jargon ('Admin Spine layout', 'chosen geometry bank', 'lane ceilings') that costs the reader more than it returns. Several clauses could be tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the description wisely summarizes the preflight shape rather than re-documenting returns. It covers the access restriction, historical-version policy, and admin-scope constraint, which is thorough for a 6-parameter nested tool; only the opaque payment/access wording leaves a gap.
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 already 83%, so baseline is 3; the description adds meaning beyond it by framing the three oneOf modes (single loc_id, exact loc_ids batch, parent_loc_id+admin_level scope) and clarifying that include_polygon gates the coordinate payload. It does not add syntax detail for batch_id/request_id, but those are trivial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource with scope: 'Shape availability and bounded coordinate retrieval only', then explicitly names what it does NOT do ('get_geometry does not return those place details'). An agent can separate it from get_loc_id_info without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit invocation conditions ('use when you already have exact loc_ids, or one administrative parent_loc_id plus target admin_level') and names the alternative for the excluded cases ('Use get_loc_id_info for hierarchy, identity, catalog coverage, or crosswalk facts'). Routing is fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_loc_id_infoInspect Known loc_id IdentitiesARead-onlyIdempotentInspect
Known-place navigation and enrichment tool: use only when you already have one canonical loc_id or a bounded loc_ids array. It returns identity, strict stored parentage, lifecycle, shape status, and place-specific data-pack and geometry-family availability with executable next calls. It does not list the global catalog and does not return polygon coordinates; use get_catalog to browse everything or get_geometry for shapes. Set include_hierarchy for same-release ancestors and include_references for maintained external or cross-family connections. Historical records are never replaced automatically. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| iso3 | No | Optional country hint for crosswalk artifacts. Defaults to the loc_id country when possible. | |
| loc_id | No | DaedalMap loc_id, e.g. 'USA-CA'. | |
| loc_ids | No | DaedalMap loc_ids to inspect together, including every loc_id from a resolve_point stack. Default public cap is deployment-configurable. | |
| systems | No | Optional reference systems to include when include_references is true, such as zcta, nws_fire, overlay_tribal, or overlay_nws_public_zone. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| min_share | No | Optional minimum target-area share for reverse overlap references. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| limit_per_system | No | Maximum overlap references to return per bridge/system. Default 10. | |
| include_hierarchy | No | When true, include strict stored parent and ancestor data. This never invents a parent edge across mixed releases. Default false. | |
| include_references | No | When true, include known external or side-chain references attached to each loc_id. Default false. | |
| target_admin_level | No | Admin level for crosswalk-backed reverse reference lookup. Inferred when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| iso3 | No | |
| name | No | |
| error | No | |
| family | No | |
| loc_id | No | |
| reason | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| hierarchy | No | |
| next_step | No | |
| data_packs | No | |
| next_calls | No | |
| references | No | |
| request_id | No | |
| admin_level | No | |
| found_count | No | |
| loc_id_count | No | |
| clarification | No | |
| meter_receipt | No | |
| missing_count | No | |
| requested_loc_id | No | |
| geometry_families | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: 'Historical records are never replaced automatically' and 'No payment required.' This enriches the agent's understanding of side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact given the tool's complexity. It front-loads the purpose, then scopes usage, then lists exclusions, then mentions key flags and behavioral caveats. Every sentence serves a distinct function, though the phrase 'executable next calls' is slightly vague and could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with an output schema and strong annotations, the description covers the return contents, usage conditions, exclusions, and important behavioral notes (historical record handling, payment). The only minor gap is the vague 'executable next calls,' but overall it is comprehensive enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 11 parameters. The description only mentions include_hierarchy and include_references in passing, without adding semantics beyond the schema. Baseline 3 applies because the schema does the heavy lifting and the description adds minimal extra parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific purpose: 'Known-place navigation and enrichment tool' and lists what it returns (identity, strict stored parentage, lifecycle, shape status, data-pack/geometry availability). Clearly distinguishes from siblings by noting it does not list the global catalog and does not return polygon coordinates, naming get_catalog and get_geometry as the appropriate alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly sets the precondition: 'use only when you already have one canonical loc_id or a bounded loc_ids array.' Also provides when-not guidance ('does not list the global catalog') and names the alternatives (get_catalog, get_geometry). This is unambiguous usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packInspect One Selected Pack or Geometry FamilyARead-onlyIdempotentInspect
Inspect one selected data pack or geometry family progressively: lite starter contract, full MCP query metadata, or a raw metadata download URL. Use its next_step to retrieve data or call the preferred geometry tool.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file. | lite |
| catalog | No | Metadata family. When omitted, geometry facades default to geometry and known geometry-family ids are inferred; all other calls default to data. | |
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. | |
| release_unit | No | Optional non-country geometry release unit such as GLOBAL or MARINE. Do not combine with country_scope. | |
| country_scope | No | Optional ISO3 country for a geometry family. Omit it to learn which countries publish the family; provide it for country-specific versions, vintages, levels, and artifacts. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| detail | No | |
| reason | No | |
| catalog | No | |
| pack_id | No | |
| sources | No | |
| guidance | No | |
| warnings | No | |
| full_call | No | |
| next_step | No | |
| provenance | No | |
| request_id | No | |
| download_url | No | |
| clarification | No | |
| download_call | No | |
| material_policy | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds behavioral value by revealing that results include a next_step for progression and that detail levels map to lite vs full metadata vs download URL. This goes beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the core purpose and then give the key follow-up behavior. There is no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich input schema and an output schema, the description covers the essential workflow and progression. The only mild gap is that 'preferred geometry tool' is not named explicitly, but the sibling list and schema make the intended routing reasonably discoverable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters in detail. The description adds only mild semantic framing ('lite starter contract') and mostly restates the detail-level behavior already present in the schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Inspect', and a specific resource, 'one selected data pack or geometry family', and names three progressive modes (lite, full, download). It also differentiates from siblings by framing get_pack as operating on a single selected item while get_catalog lists and get_data retrieves data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable guidance: use it to inspect a selected pack, and then 'Use its next_step to retrieve data or call the preferred geometry tool.' It implies a sequential workflow but does not explicitly state when to prefer get_data or get_catalog instead, so it falls just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tool_helpGet Tool HelpARead-onlyIdempotentInspect
Describe one tool visible on this facade, including its exact contract, or return a bounded workflow overview for one supported topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Workflow overview. Do not combine with tool_name. | |
| question | No | Optional question used only with a topic overview. | |
| tool_name | No | Exact tool name from tools/list. Do not combine with topic. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| title | No | |
| access | No | |
| reason | No | |
| purpose | No | |
| examples | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| tool_name | No | |
| provenance | No | |
| request_id | No | |
| input_schema | No | |
| clarification | No | |
| recommended_next_calls | No | |
| important_output_fields | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds a bit of behavioral context by mentioning 'exact contract' and 'bounded workflow overview', but it does not disclose potential error conditions or response formats. This is acceptable given the annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently presents both modes without redundancy. Every phrase adds value, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate but relies heavily on the schema for constraints (e.g., oneOf logic, enum values, mutual exclusivity). It does not mention optional parameters or edge cases, but given the rich schema and annotations, it covers the essential purpose. A 3 reflects that it is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a thorough description (e.g., 'Do not combine with tool_name'). The tool description adds no extra parameter detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: describe a tool (with its exact contract) or return a workflow overview for a supported topic. It uses specific verbs and resources, and the two modes are distinct. This differentiates it from sibling data-fetching tools like get_data and get_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use each mode by stating the two options, and the schema enforces mutual exclusivity. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., for actual data retrieval). Still, the purpose is clear enough for an agent to infer correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identify_dataset_geographyChoose Geography Columns From a DatasetARead-onlyIdempotentInspect
Multi-column dataset classifier: use when you do not yet know which column or latitude/longitude pair represents geography. Pass bounded samples from several named scalar columns; it selects the plausible geography column(s), then proposes a country, level, and maintained reference-system binding. It does not validate a preselected identifier column value-by-value; after selecting a code column, use identify_reference_system when explicit verification is needed. Returns up to three reviewable bindings and recommends only an unambiguous high-confidence result. No geometry is loaded and no full dataset is retained. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| columns | Yes | Structurally filtered columns with deterministic representative scalar values. Do not pre-label their geographic system. | |
| request_id | No | ||
| country_scope | No | Optional caller-declared ISO3 hint. Omit when unknown. | |
| dataset_context | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| limit | No | |
| reason | No | |
| status | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| candidates | No | |
| request_id | No | |
| column_count | No | |
| clarification | No | |
| meter_receipt | No | |
| review_required | No | |
| identifier_count | No | |
| coordinate_binding | No | |
| settlement_receipt | No | |
| recommended_binding | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: it returns up to three reviewable bindings, recommends only unambiguous high-confidence results, loads no geometry, retains no full dataset, and requires no payment. This gives agents a clear picture of operational side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. The opening phrase frames the tool as a classifier and the primary use case, followed by concrete operational details, exclusions, and output characteristics. No filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the essential call context: when to use, what to pass, what it returns (up to three bindings, no geometry loaded), and how it relates to a sibling tool. The only not-explicitly-stated edge cases (e.g., ambiguous input) are adequately hinted by 'recommends only an unambiguous high-confidence result.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, so the description compensates by explaining the meaning of the core 'columns' parameter: pass bounded samples from several named scalar columns, and do not pre-label their geographic system. It also clarifies country_scope as an ISO3 hint. However, request_id and dataset_context are not elaborated in the description, leaving some params undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('selects', 'proposes') and a precise resource ('geography columns from a dataset'). It clearly differentiates from the sibling identify_reference_system by explaining this tool is for discovering geography columns when unknown, not for validating a preselected code column.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use when you do not yet know which column or latitude/longitude pair represents geography.' It also names the alternative (identify_reference_system) and the condition for switching (after selecting a code column, when explicit verification is needed). No ambiguity about when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
identify_reference_systemIdentify One Identifier Column's Reference SystemARead-onlyIdempotentInspect
Single-column code-system classifier: use after an identifier column has already been selected, or to inspect one bounded set of like geography codes. Pass only identifier strings from that one field so leading zeros are preserved. It determines or verifies the system, country, level, vintage, and compatible geometry bank; it does not choose among dataset columns, convert the full dataset, or return polygons. Use identify_dataset_geography instead when column selection is still unknown. Ambiguous results remain unselected until the caller retries with expected.system; a known system can be verified by supplying expected on the first call. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| expected | No | ||
| identifier | No | One geography identifier to inspect. | |
| request_id | No | Optional caller-supplied request id for tracing. | |
| identifiers | No | A bounded representative identifier sample. Duplicate values are checked once. Values must be strings so leading zeros are preserved. | |
| country_scope | No | Optional ISO3 country hint used to narrow candidate banks. | |
| dataset_context | No | Bounded, non-row dataset clues used to rank plausible interpretations without replacing exact identifier verification. | |
| validation_scope | No | Describes whether the bounded input is a sample or, only when it fits the identification cap, the complete distinct-key set. This tool validates every supplied identifier; create_conversion_job validates every row in the full dataset. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| limit | No | |
| reason | No | |
| status | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| candidates | No | |
| request_id | No | |
| column_count | No | |
| clarification | No | |
| meter_receipt | No | |
| review_required | No | |
| identifier_count | No | |
| coordinate_binding | No | |
| settlement_receipt | No | |
| recommended_binding | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds substantial context: 'No payment required', 'does not choose among dataset columns, convert the full dataset, or return polygons', and the retry behavior for ambiguous results. It also explains that input values must be strings to preserve leading zeros. These add real value beyond the annotations and clarify what the tool will and won't do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, usage condition, input guidance, scope exclusions, alternative routing, retry behavior, and payment. It is front-loaded with the core purpose and has no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, nested objects, anyOf constraints, and an output schema, the description covers selection logic, input constraints, behavioral exclusions, and alternative routing. The output schema handles return details, and the description leaves no critical gap for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the baseline is 3. The description adds meaningful guidance: passing only strings from one field to preserve leading zeros, using expected.system for verification or retry, and clarifying dataset_context as 'bounded, non-row dataset clues' and validation_scope as covering every supplied identifier. These clarifications go beyond the schema, though they don't enumerate every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it is a 'single-column code-system classifier' and lists exactly what it determines (system, country, level, vintage, compatible geometry bank). Explicitly distinguishes from identify_dataset_geography by naming the sibling and the condition that selects it. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('use after an identifier column has already been selected, or to inspect one bounded set') and when-not ('Use identify_dataset_geography instead when column selection is still unknown'). Also instructs to pass only identifier strings to preserve leading zeros and explains how to use expected for verification or retry. Clear, actionable guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_deep_pointResolve Point(s) (Deep)ARead-onlyIdempotentInspect
Second-pass resolution for one WGS84 coordinate or a bounded point array. Supply one shared shallow_loc_id returned by resolve_point and one canonical family from get_catalog(catalog='geometry'). family defaults to administrative; shape-backed families use direct bbox-to-exact-shape lookup without crosswalks. Single and bulk requests share this scoped contract. 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| point | No | |
| stack | No | |
| family | No | |
| reason | No | |
| matched | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| join_keys | No | |
| next_step | No | |
| request_id | No | |
| point_count | No | |
| clarification | No | |
| family_result | No | |
| meter_receipt | No | |
| resolved_count | No | |
| shallow_loc_id | No | |
| deeper_available | No | |
| overlap_families | No | |
| unresolved_count | No | |
| settlement_receipt | No | |
| deepest_resolved_family | No | |
| deepest_resolved_loc_id | No | |
| deepest_resolved_admin_level | No | |
| available_deeper_admin_levels | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond that: it reveals the bbox-to-exact-shape lookup strategy for shape-backed families and the scoped contract shared by single and bulk requests, plus geographic coverage nuances such as automatic deeper tiers for certain countries. 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 core usage description is front-loaded and tight: purpose, required inputs, family default, and lookup behavior fit into the first few sentences. The final 'Current catalog' paragraph is informative but somewhat lengthy and could be trimmed; still, it is organized and not redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with 8 parameters, a oneOf constraint, and an output schema, the description covers the essential operational context: second-pass nature, required upstream inputs, family behavior, and data availability. The points array scope is reinforced ('bounded point array' matches the schema's 'Points already known to fall within the supplied shallow_loc_id scope'), and the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how to source the shallow_loc_id and family parameters, that family defaults to administrative, and that shape-backed families behave differently. This goes beyond the schema's field-level descriptions, though it doesn't detail every parameter because the schema already does.
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 'Second-pass resolution for one WGS84 coordinate or a bounded point array,' naming a specific verb, resource, and scope. It also explicitly ties to sibling tools by requiring a shallow_loc_id 'returned by resolve_point' and a family 'from get_catalog(catalog='geometry')', making the tool's role and differentiation unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the invocation contract: supply a shallow_loc_id from resolve_point and a canonical family from get_catalog. It also notes that family defaults to administrative and that shape-backed families use direct lookup without crosswalks, giving clear context on when to use this deep-resolution path. It doesn't explicitly enumerate when-not-to-use cases, so it falls just short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_pointResolve Point(s) (Shallow)ARead-onlyIdempotentInspect
Compact first-pass reverse geocoding for one WGS84 coordinate or a bounded point array. Returns the deepest available administrative loc_id chain: the global baseline reaches Admin 2, while adopted country query banks may reach Admin 3. It does not open 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 | Opt in to parallel Marine overlaps for land matches. Defaults to false so ordinary administrative resolution stays lightweight. Offshore Marine fallback still applies. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| point | No | |
| stack | No | |
| family | No | |
| reason | No | |
| matched | No | |
| results | No | |
| batch_id | No | |
| guidance | No | |
| warnings | No | |
| join_keys | No | |
| next_step | No | |
| request_id | No | |
| point_count | No | |
| clarification | No | |
| family_result | No | |
| meter_receipt | No | |
| resolved_count | No | |
| shallow_loc_id | No | |
| deeper_available | No | |
| overlap_families | No | |
| unresolved_count | No | |
| settlement_receipt | No | |
| deepest_resolved_family | No | |
| deepest_resolved_loc_id | No | |
| deepest_resolved_admin_level | No | |
| available_deeper_admin_levels | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral context: the returned loc_id chain depth (baseline Admin 2, adopted banks to Admin 3), what it explicitly does NOT do (no deep partitions, no side-family shape banks), and that access limits scale with point count. This is substantive disclosure 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 first two sentences are tightly front-loaded and carry the core scope plus the deep/shallow routing. The trailing catalog paragraph is informative about coverage depth but is comparatively verbose and partly overlaps what get_catalog would provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values needn't be spelled out, and annotations cover the safety profile. The description still supplies scope, alternative routing, depth guarantees, and access-limit behavior, leaving nothing an agent needs to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents lat/lon bounds, the points array, target_admin_level's Admin 0-3 range, and the marine flag. The description mostly restates these (e.g. deepest available shallow level) rather than adding syntax or edge-case semantics, so the baseline 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?
States a specific verb (reverse geocode/resolve) and resource (one WGS84 coordinate or bounded point array), and immediately positions itself against the sibling resolve_deep_point by scope (shallow vs deep). An agent can distinguish it from resolve_deep_point without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: use this for a compact first pass, then feed the returned shallow loc_id into resolve_deep_point for Admin 4-6 or one explicit family. The alternative and the condition that selects it are both named, and it states that single and bulk requests share the same contract.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
resolve_point2 fields changed- added
Input schema / properties / include_marine_context / defaultAdded value: +false - changed
Input schema / properties / include_marine_context / descriptionPrevious value: -"Include parallel Marine overlaps for land matches. Defaults to true; set false for fast administrative loc_id previews. Offshore Marine fallback still applies."New value: +"Opt in to parallel Marine overlaps for land matches. Defaults to false so ordinary administrative resolution stays lightweight. Offshore Marine fallback still applies."
8 tool updates
- Changed
compare_geographies1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "spatial_relation" + ] + }, + { + "required": [ + "item_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "compared_count": { + "minimum": 0, + "type": "integer" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "failed_count": { + "minimum": 0, + "type": "integer" + }, + "guidance": { + "type": "object" + }, + "item_count": { + "minimum": 0, + "type": "integer" + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "spatial_relation": { + "type": [ + "string", + "object", + "null" + ] + }, + "temporal_relation": { + "type": [ + "string", + "object", + "null" + ] + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
convert_reference1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "results" + ] + }, + { + "required": [ + "item_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "converted_count": { + "minimum": 0, + "type": "integer" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "from": { + "type": "object" + }, + "from_system": { + "type": "string" + }, + "guidance": { + "type": "object" + }, + "item_count": { + "minimum": 0, + "type": "integer" + }, + "loc_id": { + "type": [ + "string", + "null" + ] + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "to_system": { + "type": "string" + }, + "unconverted_count": { + "minimum": 0, + "type": "integer" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_geometry1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "selection", + "items" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "available": { + "minimum": 0, + "type": "integer" + }, + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "guidance": { + "type": "object" + }, + "include_polygon": { + "type": "boolean" + }, + "items": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "meter_receipt": { + "type": "object" + }, + "missing": { + "minimum": 0, + "type": "integer" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "requested": { + "minimum": 0, + "type": "integer" + }, + "scope": { + "type": [ + "object", + "null" + ] + }, + "selection": { + "enum": [ + "exact_loc_ids", + "admin_scope" + ], + "type": "string" + }, + "settlement_receipt": { + "type": "object" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_loc_id_info1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "loc_id" + ] + }, + { + "required": [ + "loc_id_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "admin_level": { + "type": [ + "string", + "integer", + "null" + ] + }, + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "data_packs": { + "type": "array" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "family": { + "type": [ + "string", + "null" + ] + }, + "found_count": { + "minimum": 0, + "type": "integer" + }, + "geometry_families": { + "type": "array" + }, + "guidance": { + "type": "object" + }, + "hierarchy": { + "type": "object" + }, + "iso3": { + "type": [ + "string", + "null" + ] + }, + "loc_id": { + "type": "string" + }, + "loc_id_count": { + "minimum": 0, + "type": "integer" + }, + "meter_receipt": { + "type": "object" + }, + "missing_count": { + "minimum": 0, + "type": "integer" + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "next_calls": { + "type": "array" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "references": { + "type": "object" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "requested_loc_id": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
identify_dataset_geography1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "status", + "candidates" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "candidates": { + "items": { + "type": "object" + }, + "type": "array" + }, + "clarification": { + "type": "object" + }, + "column_count": { + "minimum": 0, + "type": "integer" + }, + "coordinate_binding": { + "type": [ + "object", + "null" + ] + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "guidance": { + "type": "object" + }, + "identifier_count": { + "minimum": 0, + "type": "integer" + }, + "limit": { + "minimum": 0, + "type": "integer" + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "recommended_binding": { + "type": [ + "object", + "null" + ] + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "review_required": { + "type": "boolean" + }, + "settlement_receipt": { + "type": "object" + }, + "status": { + "type": "string" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
identify_reference_system1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "status", + "candidates" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "candidates": { + "items": { + "type": "object" + }, + "type": "array" + }, + "clarification": { + "type": "object" + }, + "column_count": { + "minimum": 0, + "type": "integer" + }, + "coordinate_binding": { + "type": [ + "object", + "null" + ] + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "guidance": { + "type": "object" + }, + "identifier_count": { + "minimum": 0, + "type": "integer" + }, + "limit": { + "minimum": 0, + "type": "integer" + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "reason": { + "type": "string" + }, + "recommended_binding": { + "type": [ + "object", + "null" + ] + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "review_required": { + "type": "boolean" + }, + "settlement_receipt": { + "type": "object" + }, + "status": { + "type": "string" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
resolve_deep_point1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "point", + "stack" + ] + }, + { + "required": [ + "point", + "family", + "family_result" + ] + }, + { + "required": [ + "point_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "available_deeper_admin_levels": { + "type": "array" + }, + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "deeper_available": { + "type": "boolean" + }, + "deepest_resolved_admin_level": { + "type": [ + "string", + "integer", + "null" + ] + }, + "deepest_resolved_family": { + "type": [ + "string", + "null" + ] + }, + "deepest_resolved_loc_id": { + "type": [ + "string", + "null" + ] + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "family": { + "type": "string" + }, + "family_result": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "join_keys": { + "type": "object" + }, + "matched": { + "type": [ + "object", + "null" + ] + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "overlap_families": { + "items": { + "type": "object" + }, + "type": "array" + }, + "point": { + "anyOf": [ + { + "additionalProperties": true, + "properties": { + "lat": { + "type": "number" + }, + "lon": { + "type": "number" + } + }, + "required": [ + "lat", + "lon" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "point_count": { + "minimum": 0, + "type": "integer" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "resolved_count": { + "minimum": 0, + "type": "integer" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "shallow_loc_id": { + "type": "string" + }, + "stack": { + "items": { + "type": "object" + }, + "type": "array" + }, + "unresolved_count": { + "minimum": 0, + "type": "integer" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
resolve_point1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "point", + "stack" + ] + }, + { + "required": [ + "point", + "family", + "family_result" + ] + }, + { + "required": [ + "point_count", + "results" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "available_deeper_admin_levels": { + "type": "array" + }, + "batch_id": { + "type": [ + "string", + "null" + ] + }, + "clarification": { + "type": "object" + }, + "deeper_available": { + "type": "boolean" + }, + "deepest_resolved_admin_level": { + "type": [ + "string", + "integer", + "null" + ] + }, + "deepest_resolved_family": { + "type": [ + "string", + "null" + ] + }, + "deepest_resolved_loc_id": { + "type": [ + "string", + "null" + ] + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "family": { + "type": "string" + }, + "family_result": { + "type": "object" + }, + "guidance": { + "type": "object" + }, + "join_keys": { + "type": "object" + }, + "matched": { + "type": [ + "object", + "null" + ] + }, + "meter_receipt": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "action" + ] + }, + { + "required": [ + "tool" + ] + } + ], + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "overlap_families": { + "items": { + "type": "object" + }, + "type": "array" + }, + "point": { + "anyOf": [ + { + "additionalProperties": true, + "properties": { + "lat": { + "type": "number" + }, + "lon": { + "type": "number" + } + }, + "required": [ + "lat", + "lon" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "point_count": { + "minimum": 0, + "type": "integer" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "resolved_count": { + "minimum": 0, + "type": "integer" + }, + "results": { + "items": { + "additionalProperties": true, + "properties": { + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "id": { + "type": [ + "string", + "integer", + "null" + ] + }, + "ok": { + "type": "boolean" + }, + "row_index": { + "type": [ + "string", + "integer", + "null" + ] + } + }, + "type": "object" + }, + "type": "array" + }, + "settlement_receipt": { + "type": "object" + }, + "shallow_loc_id": { + "type": "string" + }, + "stack": { + "items": { + "type": "object" + }, + "type": "array" + }, + "unresolved_count": { + "minimum": 0, + "type": "integer" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
1 tool update
- Changed
get_catalog2 fields changed- added
Input schema / properties / loc_idAdded value: +{ + "description": "Optional DaedalMap loc_id for catalog='data'. Combine with time_range to discover packs confirmed for both place and time. For place details without pack filtering, use get_loc_id_info.", + "type": "string" +} - added
Input schema / properties / time_rangeAdded value: +{ + "additionalProperties": false, + "description": "Optional inclusive discovery window for catalog='data'. At least one bound is required.", + "properties": { + "end": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + }, + "start": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "integer" + } + ] + } + }, + "type": "object" +}
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
17 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" -]
- 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" +}
- 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
how_geometry_works - Removed
list_reference_systems - Removed
loc_id_info - 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
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
3 tool updates
- Changed
get_catalog1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "packs" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "catalog_version": { + "type": "string" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "generated_at": { + "type": [ + "string", + "null" + ] + }, + "guidance": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_count": { + "minimum": 0, + "type": "integer" + }, + "packs": { + "items": { + "type": "object" + }, + "type": "array" + }, + "provenance": { + "type": "object" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "tool_families": { + "items": { + "type": "object" + }, + "type": "array" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_pack1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "pack_id" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "guidance": { + "type": "object" + }, + "material_policy": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "pack_id": { + "type": "string" + }, + "provenance": { + "type": "object" + }, + "reason": { + "type": "string" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "sources": { + "items": { + "type": "object" + }, + "type": "array" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
get_tool_help1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": true, + "anyOf": [ + { + "required": [ + "ok", + "tool_name" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "access": { + "type": "object" + }, + "clarification": { + "type": "object" + }, + "error": { + "additionalProperties": true, + "properties": { + "code": { + "type": "string" + }, + "details": { + "type": "object" + }, + "message": { + "type": "string" + }, + "retry_hint": { + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" + }, + "examples": { + "type": "array" + }, + "guidance": { + "type": "object" + }, + "important_output_fields": { + "type": "array" + }, + "input_schema": { + "type": "object" + }, + "next_step": { + "additionalProperties": true, + "properties": { + "action": { + "type": "string" + }, + "arguments": { + "type": "object" + }, + "tool": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "action" + ], + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "provenance": { + "type": "object" + }, + "purpose": { + "type": "string" + }, + "reason": { + "type": "string" + }, + "recommended_next_calls": { + "type": "array" + }, + "request_id": { + "type": [ + "string", + "null" + ] + }, + "title": { + "type": [ + "string", + "null" + ] + }, + "tool_name": { + "type": "string" + }, + "warnings": { + "items": { + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
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."
Related MCP Connectors
Convert WGS84 coordinates to the latest available administrative loc_id chain.
Resolve coordinates against delivery and coverage polygons (geofences).
Retrieve loc_id boundary metadata, polygons, supported scopes, and comparisons.
Resolves IP autonomous system numbers (ASN) and geographic coordinates.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables resolving US latitude/longitude points to Census block, county, and state FIPS codes and names, along with 2020 block population and FCC market-area codes when needed.337 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables forward and reverse geocoding of US addresses, returning coordinates and the full Census geography stack with GEOIDs, including batch geocoding of up to 100 addresses.MIT
- AlicenseAqualityDmaintenanceProvides forward/reverse geocoding, bounding box extraction, nearby places discovery, batch geocoding, route waypoints, and administrative boundary lookup using OpenStreetMap data.10Apache 2.0

atlasfetch-mcpofficial
AlicenseAqualityAmaintenanceEnables reverse geocoding of coordinates to country, region, and municipality with ISO 3166 codes, and matching against user-defined geofences.4268 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.