DaedalMap Administrative Boundaries (loc_id to polygon)
Server Details
Retrieve loc_id boundary metadata, polygons, supported scopes, and comparisons.
- Status
- Healthy
- Uptime
- 96.3% over 67 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 7 tools
Most tools target clearly distinct operations (compare relationships, look up identity/connections, fetch geometry, browse catalog), and the descriptions explicitly fence off responsibilities (e.g. compare_geographies 'never reads polygons'). However, get_catalog, get_geography, and get_pack form a metadata-browsing cluster whose boundaries require careful reading to separate, and compare_geographies vs get_loc_id_info both touch relationship evidence.
Six of seven tools follow a clean get_<noun> pattern (get_catalog, get_geography, get_loc_id_info, get_pack, get_shape, get_tool_help). Only compare_geographies deviates with a different verb, which is a minor but noticeable break in an otherwise uniform convention.
Seven tools is well within the sweet spot for a read-oriented geography/boundary service. Each tool maps to a distinct step in the lookup workflow (discover catalog, inspect metadata, resolve IDs, fetch geometry, compare, help), so none feels redundant.
The surface covers the core lifecycle: catalog discovery, pack/geography inspection, loc_id resolution, shape retrieval, and relationship comparison. Minor gaps exist—external identifier bridging is explicitly out of scope, get_shape lacks year selection, and batch shape retrieval is absent—but agents can work around these.
Available Tools
7 toolscompare_geographiesCompare Geographic IdentitiesARead-onlyIdempotentInspect
Compare two known loc_ids using selected reference-graph identity and direct relationship evidence. Verified Admin ancestry can prove containment; a typed graph edge can prove only the relation it declares. An explicit negative edge returns no_overlap; a missing edge returns unknown. This tool never reads polygons or computes shape intersections. Use an external identifier bridge before this call when the input is not a loc_id. 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 | |
| graph_evidence | No | |
| geometry_loaded | No | |
| spatial_relation | No | |
| temporal_relation | No | |
| relationship_basis | No | |
| settlement_receipt | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral detail beyond that: an explicit negative edge yields no_overlap while a missing edge yields unknown, Admin ancestry can prove containment but a typed edge proves only its declared relation, and it never reads polygons. This meaningfully improves result interpretation.
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?
Front-loaded with the core action and the proof model, then covers edge outcomes, scope limits, and prerequisites in a compact sequence. It is dense but every sentence carries distinct information; minor tightening is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and complete annotation coverage, so return values and safety need not be restated. The description supplies the interpretive rules (no_overlap vs unknown) and the identifier-bridge prerequisite, leaving little an agent needs to infer before calling 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 100%, so all nine parameters are already documented in the schema (including as_of overrides and include_successors default). The description adds no additional per-parameter syntax or format detail beyond that, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Compare) and resource (known loc_ids / geographic identities) with a precise scope: reference-graph identity plus direct relationship evidence. It also carves out what it is not – a polygon/geometry-intersection tool – which implicitly separates it from get_shape and get_geography. It stops short of naming a sibling by name, so it is clear but not fully differentiated.
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 a concrete prerequisite: 'Use an external identifier bridge before this call when the input is not a loc_id.' This tells the agent when the tool is applicable and what to do first. It does not, however, explicitly name an alternative tool or state a when-not condition for already-valid loc_ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_catalogList Published Packs or GeographiesARead-onlyIdempotentInspect
Choose data or geometry to list published pack IDs or family and scope IDs. The response includes a complete catalog download URL. Use get_pack for data or get_geography for geometry. 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 |
|---|---|---|---|
| catalog | Yes | Required directory selector. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| packs | No | |
| detail | No | |
| reason | No | |
| scopes | No | |
| catalog | No | |
| families | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| pack_count | No | |
| provenance | No | |
| request_id | No | |
| download_url | No | |
| generated_at | No | |
| clarification | No | |
| result_status | No | |
| tool_families | No | |
| excluded_count | No | |
| resolved_query | No | |
| catalog_version | No | |
| uncertain_count | No | |
| uncertain_packs | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description's only behavioral addition is that the response carries a catalog download URL, which is already implied by the output schema; the long paragraph about worldwide coverage and per-country releases is scope marketing rather than behavioral 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 actionable content (what it lists, the download URL, the get_pack/get_geography routing) is front-loaded, but it is then buried under a lengthy 'Current catalog' paragraph listing 252 entities and eight countries that does nothing for tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and an output schema covering returns, the description only needs to explain the selector and routing, which it mostly does. However, the undefined 'scope IDs' terminology and the routing to a non-sibling tool leave small gaps for an agent deciding between catalog and pack calls.
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% and the enum values are self-explanatory, so the baseline is 3. The description goes beyond this by mapping each enum value to a distinct return shape ('data' yields pack IDs, 'geometry' yields family and scope IDs), which genuinely adds meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It names a specific verb ('list') and resource ('published pack IDs or family and scope IDs') and ties the output to the required catalog selector. It is distinguishable from the generic get_data/get_pack siblings, though the phrase 'family and scope IDs' is jargon that is never defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing: 'Use get_pack for data or get_geography for geometry,' which tells the agent when to pick this tool over an alternative. The weakness is that get_geography is not among the listed siblings, so the routing target is ambiguous for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_geographyInspect One Geography Family or ScopeARead-onlyIdempotentInspect
Inspect one published geometry family across scopes or one scope across families. Returns coverage and known editions from catalog metadata only. Optional year selects the latest admitted edition no later than that year when the selected catalog has an edition index; an unavailable index is reported explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| scope_id | No | ||
| family_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| reason | No | |
| catalog | No | |
| coverage | No | |
| guidance | No | |
| scope_id | No | |
| warnings | No | |
| family_id | No | |
| next_step | No | |
| provenance | No | |
| request_id | No | |
| admin_spine | No | |
| clarification | No | |
| requested_year | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, closed-world and non-destructive behavior, so the bar is lower. The description still adds real context: results come from catalog metadata only, the optional year resolves to the latest admitted edition no later than that year, and a missing edition index is reported explicitly rather than silently ignored.
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 tight sentences with no filler, and the core operation is front-loaded before the year-selection detail. The phrasing is jargon-dense but each sentence carries 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?
With an output schema present, return values need no further explanation, and the annotations cover the safety profile. The description covers the operation and the year behavior adequately; the only real gap is not clarifying the family_id/scope_id distinction and their mutual exclusivity.
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 0%, so the description carries the burden for three parameters. It explains 'year' semantics well (latest admitted edition no later than the year, with explicit reporting when no index exists), but says nothing about the meaning of family_id vs scope_id or the oneOf exclusivity rule that requires exactly one of them.
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 ('Inspect') and resource ('one published geometry family across scopes or one scope across families'), which distinguishes it from siblings like compare_geographies, get_shape, and get_data. It is clear what the tool returns, though the family-vs-scope duality is stated rather densely and its relationship to sibling tools is not explicitly contrasted.
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 phrase 'from catalog metadata only' implicitly signals this is a metadata lookup rather than a data/geometry fetch (vs get_data, get_shape), which gives an agent some routing signal. However, there is no explicit when-to-use, when-not-to-use, or named alternative sibling, so usage must be inferred.
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 Direct loc_id ConnectionsARead-onlyIdempotentInspect
Look up one known loc_id or a small batch in the selected reference graph. Return its identity and directly recorded loc_id connections, with family, direction, and relationship evidence. Each ID returns at most 50 connections and an explicit has_more flag. This tool does not expand descendants, infer containment, read shapes, search catalogs, or consult external adapters. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| loc_id | No | DaedalMap loc_id, e.g. 'USA-CA'. | |
| loc_ids | No | Up to 10 known loc_ids, including a resolve_point stack. | |
| batch_id | No | Optional caller-supplied batch id for tracing. | |
| request_id | No | Optional caller-supplied request id for tracing. |
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 | |
| has_more | No | |
| warnings | No | |
| next_step | No | |
| request_id | No | |
| admin_level | No | |
| connections | No | |
| found_count | No | |
| loc_id_count | No | |
| clarification | No | |
| meter_receipt | No | |
| missing_count | No | |
| connection_count | No | |
| connection_limit | No | |
| requested_loc_id | 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, so the safety burden is covered. The description still adds real behavioral context beyond them: a per-ID cap of 50 connections with an explicit has_more flag (pagination semantics), the silent-exclusion behaviors, and the note that no payment is required, which signals a possible paid path elsewhere.
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?
Front-loaded with the core operation and the return shape, then the scope exclusions, then the payment note. It is dense and nearly every clause earns its place; the exclusion list is somewhat long but directly serves disambiguation, which justifies the length.
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, so return values need not be described, and annotations cover the safety profile. The description supplies the remaining missing pieces an agent needs to call this correctly: known-ID-only precondition, batch size, truncation limit, has_more signaling, and the explicit boundary against adjacent tools.
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 loc_id, loc_ids, batch_id and request_id are already documented, and the baseline is 3. The description only echoes the single-ID-or-batch shape; it adds no format, resolution or tracing semantics beyond what the schema states, and notably does not explain the 'resolve_point stack' behavior described in loc_ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (look up a loc_id or small batch in the selected reference graph) and defines the exact return payload: identity plus directly recorded connections with family, direction and evidence. The explicit negative scope ('does not expand descendants, infer containment, read shapes, search catalogs') cleanly separates it from siblings like get_geography, get_shape, 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 establishes the usage condition well: it operates on known IDs only, supports a single ID or a batch, and explicitly refuses expansion, inference, shape reads, catalog search and adapter calls. It stops short of naming the sibling tools an agent should reach for instead when it does need shapes or catalog search, so routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packInspect One Data PackARead-onlyIdempotentInspect
Inspect one exact data pack ID for its metrics, time coverage, and query metadata before get_data.
| Name | Required | Description | Default |
|---|---|---|---|
| pack_id | Yes | Pack identifier from get_catalog. Newly catalog-admitted packs require no MCP schema change. |
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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's additional value is the pre-flight framing (cheap inspection ahead of get_data) and a summary of returned content. It does not add anything about unknown-ID behavior or lookup cost, so it is solid but not rich.
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?
A single sentence that front-loads the verb and resource and ends with the routing cue. Every clause carries information; nothing is padded or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate return fields, and annotations plus a 100%-covered single parameter handle the rest. The only thin spot is behavior when an unknown or stale pack ID is passed, which the description never touches.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single pack_id parameter is well documented in the schema itself (origin in get_catalog, note about newly admitted packs). The description only adds the emphasis that the ID must be exact, which is marginal but consistent with the baseline for fully covered 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?
States a specific verb (inspect), a specific resource (one exact data pack ID), and what the inspection yields (metrics, time coverage, query metadata). This cleanly separates it from get_catalog (enumeration) and get_data (retrieval) without the agent needing to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before get_data' gives an explicit sequencing rule for when this tool belongs in a workflow, and the schema's 'from get_catalog' note completes the chain. There are no stated exclusions or failure conditions, so it falls just short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_shapeRetrieve Shapes for Known loc_idsARead-onlyIdempotentInspect
Shape lookup for exact existing loc_ids only. The default returns shape availability, centroid, and bounding box; include_polygon=true adds GeoJSON coordinates. Obtain any descendant IDs before this call. Historical geometry is returned first and successors are never substituted automatically. Year selection is not yet supported.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | |
| 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?
Goes well beyond the annotations by describing the default return set (availability, centroid, bounding box), the include_polygon effect, the fallback rule that 'historical geometry is returned first and successors are never substituted automatically,' and an unsupported feature. Annotations already cover the safe-read profile; this adds genuinely non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five tight sentences with the scoping constraint and default-return behavior front-loaded. Every sentence carries information, though the density is high enough that it reads as a spec dump rather than a prioritized summary.
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 need no explanation, and the description covers the prerequisite, geometry-substitution rule, and unsupported year selection. The main residual gap is that the cap/rate behavior ('deployment-configurable') is left to the schema rather than summarized.
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 both loc_id/loc_ids and include_polygon are already documented in the schema. The description restates include_polygon's effect ('adds GeoJSON coordinates') but adds no format or syntax detail beyond what the schema provides, making the baseline 3 correct.
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 ('Shape lookup') scoped to 'exact existing loc_ids only', which implicitly distinguishes it from point-resolver siblings. However, it never names a sibling such as get_geography, so the agent must infer the boundary from the phrase 'exact existing loc_ids' rather than being told explicitly.
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?
Clear context: prerequisite 'Obtain any descendant IDs before this call', restriction to existing IDs, and the explicit limitation 'Year selection is not yet supported.' It stops short of naming the alternative tool for obtaining IDs, so routing is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tool_helpGet Tool HelpARead-onlyIdempotentInspect
Describe one tool visible on this facade, including its exact contract, or return a bounded workflow overview for one supported topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Workflow overview. Do not combine with tool_name. | |
| question | No | Optional question used only with a topic overview. | |
| tool_name | No | Exact tool name from tools/list. Do not combine with topic. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | |
| error | No | |
| title | No | |
| access | No | |
| reason | No | |
| purpose | No | |
| examples | No | |
| guidance | No | |
| warnings | No | |
| next_step | No | |
| tool_name | No | |
| provenance | No | |
| request_id | No | |
| input_schema | No | |
| clarification | No | |
| recommended_next_calls | No | |
| important_output_fields | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds a bit of behavioral context by mentioning 'exact contract' and 'bounded workflow overview', but it does not disclose potential error conditions or response formats. This is acceptable given the annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently presents both modes without redundancy. Every phrase adds value, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate but relies heavily on the schema for constraints (e.g., oneOf logic, enum values, mutual exclusivity). It does not mention optional parameters or edge cases, but given the rich schema and annotations, it covers the essential purpose. A 3 reflects that it is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has a thorough description (e.g., 'Do not combine with tool_name'). The tool description adds no extra parameter detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: describe a tool (with its exact contract) or return a workflow overview for a supported topic. It uses specific verbs and resources, and the two modes are distinct. This differentiates it from sibling data-fetching tools like get_data and get_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use each mode by stating the two options, and the schema enforces mutual exclusivity. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., for actual data retrieval). Still, the purpose is clear enough for an agent to infer correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
- Changed
compare_geographies9 fields changed- removed
Input schema / anyOfRemoved value: -[ - { - "required": [ - "left_loc_id", - "right_loc_id" - ] - }, - { - "required": [ - "items" - ] - } -] - added
Input schema / oneOfAdded value: +[ + { + "required": [ + "left_loc_id", + "right_loc_id" + ] + }, + { + "required": [ + "items" + ] + } +] - added
Input schema / properties / items / items / properties / left_loc_id / minLengthAdded value: +1 - added
Input schema / properties / items / items / properties / right_loc_id / minLengthAdded value: +1 - added
Input schema / properties / left_loc_id / minLengthAdded value: +1 - added
Input schema / properties / right_loc_id / minLengthAdded value: +1 - added
Output schema / properties / geometry_loadedAdded value: +{ + "type": "boolean" +} - added
Output schema / properties / graph_evidenceAdded value: +{ + "items": { + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / relationship_basisAdded value: +{ + "type": "string" +}
- Changed
get_catalog15 fields changed- removed
Input schema / properties / catalog / defaultRemoved value: -"data" - changed
Input schema / properties / catalog / descriptionPrevious value: -"Catalog family. The geography facade defaults to geometry; other facades default to data."New value: +"Required directory selector." - removed
Input schema / properties / country_scopeRemoved value: -{ - "description": "Optional ISO3 focus for catalog='geometry' with detail='lite'.", - "type": "string" -} - removed
Input schema / properties / detailRemoved 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" -} - removed
Input schema / properties / loc_idRemoved 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" -} - removed
Input schema / properties / time_rangeRemoved 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" -} - added
Input schema / requiredAdded value: +[ + "catalog" +] - changed
Output schema / anyOfPrevious value: -[ - { - "required": [ - "catalog", - "detail" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "required": [ + "catalog" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / excluded_countAdded value: +{ + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / familiesAdded value: +{ + "items": { + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / resolved_queryAdded value: +{ + "type": "object" +} - added
Output schema / properties / result_statusAdded value: +{ + "type": "string" +} - added
Output schema / properties / scopesAdded value: +{ + "items": { + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / uncertain_countAdded value: +{ + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / uncertain_packsAdded value: +{ + "items": { + "type": "object" + }, + "type": "array" +}
- Added
get_geography - Removed
get_geometry - Changed
get_loc_id_info22 fields changed- removed
Input schema / anyOfRemoved value: -[ - { - "required": [ - "loc_id" - ] - }, - { - "required": [ - "loc_ids" - ] - } -] - added
Input schema / oneOfAdded value: +[ + { + "required": [ + "loc_id" + ] + }, + { + "required": [ + "loc_ids" + ] + } +] - removed
Input schema / properties / as_ofRemoved value: -{ - "description": "Optional ISO day, month, or year (YYYY-MM-DD, YYYY-MM, or YYYY). Reviews the current Full source edition and returns a Double-check date alert for coarse or stale coverage; it does not select historical geometry.", - "type": "string" -} - removed
Input schema / properties / include_hierarchyRemoved value: -{ - "description": "When true, include strict stored parent and ancestor data. This never invents a parent edge across mixed releases. Default false.", - "type": "boolean" -} - removed
Input schema / properties / include_referencesRemoved value: -{ - "description": "When true, include known external or side-chain references attached to each loc_id. Default false.", - "type": "boolean" -} - removed
Input schema / properties / iso3Removed value: -{ - "description": "Optional country hint for crosswalk artifacts. Defaults to the loc_id country when possible.", - "type": "string" -} - removed
Input schema / properties / limit_per_systemRemoved value: -{ - "description": "Maximum overlap references to return per bridge/system. Default 10.", - "maximum": 100, - "minimum": 1, - "type": "integer" -} - changed
Input schema / properties / loc_ids / descriptionPrevious value: -"DaedalMap loc_ids to inspect together, including every loc_id from a resolve_point stack. Default public cap is deployment-configurable."New value: +"Up to 10 known loc_ids, including a resolve_point stack." - added
Input schema / properties / loc_ids / maxItemsAdded value: +10 - added
Input schema / properties / loc_ids / minItemsAdded value: +1 - removed
Input schema / properties / min_shareRemoved value: -{ - "description": "Optional minimum target-area share for reverse overlap references.", - "maximum": 1, - "minimum": 0, - "type": "number" -} - removed
Input schema / properties / systemsRemoved value: -{ - "description": "Optional reference systems to include when include_references is true, such as zcta, nws_fire, overlay_tribal, or overlay_nws_public_zone.", - "items": { - "type": "string" - }, - "type": "array" -} - removed
Input schema / properties / target_admin_levelRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "integer" - } - ], - "description": "Admin level for crosswalk-backed reverse reference lookup. Inferred when omitted." -} - added
Output schema / properties / connection_countAdded value: +{ + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / connection_limitAdded value: +{ + "minimum": 1, + "type": "integer" +} - added
Output schema / properties / connectionsAdded value: +{ + "items": { + "type": "object" + }, + "type": "array" +} - removed
Output schema / properties / data_packsRemoved value: -{ - "type": "array" -} - removed
Output schema / properties / geometry_familiesRemoved value: -{ - "type": "array" -} - added
Output schema / properties / has_moreAdded value: +{ + "type": "boolean" +} - removed
Output schema / properties / hierarchyRemoved value: -{ - "type": "object" -} - removed
Output schema / properties / next_callsRemoved value: -{ - "type": "array" -} - removed
Output schema / properties / referencesRemoved value: -{ - "type": "object" -}
- Changed
get_pack5 fields changed- removed
Input schema / properties / catalogRemoved 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" -} - removed
Input schema / properties / country_scopeRemoved 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" -} - removed
Input schema / properties / detailRemoved value: -{ - "default": "lite", - "description": "Use lite to decide and start, full for detailed MCP query metadata, or download for the complete raw metadata file.", - "enum": [ - "lite", - "full", - "download" - ], - "type": "string" -} - removed
Input schema / properties / release_unitRemoved 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 / properties / catalog / enumPrevious value: -[ - "data", - "geometry" -]New value: +[ + "data" +]
- Added
get_shape
1 tool update
- Changed
get_loc_id_info1 field changed- added
Input schema / properties / as_ofAdded value: +{ + "description": "Optional ISO day, month, or year (YYYY-MM-DD, YYYY-MM, or YYYY). Reviews the current Full source edition and returns a Double-check date alert for coarse or stale coverage; it does not select historical geometry.", + "type": "string" +}
3 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
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" +}
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" +}
4 tool updates
- Removed
create_geometry_export - Removed
estimate_geometry_package - Removed
get_job_status - Removed
resolve_loc_id_scope
7 tool updates
- Removed
check_geometry - 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
loc_id_info
2 tool updates
- 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" +}
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" +}
Related MCP Connectors
Resolve coordinates and geographic identifiers to loc_id, crosswalks, and bounded shapes.
Convert WGS84 coordinates to the latest available administrative loc_id chain.
Look up Indian land parcels by survey number or lat/lon. Returns parcel boundaries.
Resolve coordinates against delivery and coverage polygons (geofences).
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables access to US Census Bureau TIGERweb geographic boundary data, returning GeoJSON for states, counties, census tracts, places, ZCTAs, and congressional districts.1-
- 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.13 npmMIT

atlasfetch-mcpofficial
AlicenseAqualityAmaintenanceEnables reverse geocoding of coordinates to country, region, and municipality with ISO 3166 codes, and matching against user-defined geofences.7423 npmMIT- AlicenseAqualityCmaintenanceMCP server for the loc8n Geographic Data API. Exposes U.S. demographics, housing, mortgage, migration, employment, and geographic data as tools.2351 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.