Skip to main content
Glama

DaedalMap Disaster and Geospatial Data

Resolve Point(s) (Deep)

resolve_deep_point
Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude in WGS84 decimal degrees.
lonNoLongitude in WGS84 decimal degrees.
familyNoOne 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
pointsNoPoints already known to fall within the supplied shallow_loc_id scope.
batch_idNoOptional caller-supplied batch id echoed for point arrays.
request_idNoOptional caller-supplied request id for tracing.
shallow_loc_idYesThe deepest canonical Admin 1-3 loc_id returned by resolve_point, such as USA-NY-061-009903.
target_admin_levelNoOptional exact Admin 4-6 level. Omit for the deepest available match.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / oneOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "points"
      +      ]
      +    },
      +    "required": [
      +      "lat",
      +      "lon"
      +    ]
      +  },
      +  {
      +    "not": {
      +      "anyOf": [
      +        {
      +          "required": [
      +            "lat"
      +          ]
      +        },
      +        {
      +          "required": [
      +            "lon"
      +          ]
      +        }
      +      ]
      +    },
      +    "required": [
      +      "points"
      +    ]
      +  }
      +]
    • addedInput schema / properties / batch_id
      Added value: +{
      +  "description": "Optional caller-supplied batch id echoed for point arrays.",
      +  "type": "string"
      +}
    • addedInput schema / properties / points
      Added 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"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "lat",
      -  "lon",
      -  "shallow_loc_id"
      -]New value: +[
      +  "shallow_loc_id"
      +]
  2. Changed5 schema fields changed
    • removedInput schema / properties / admin_1_loc_id
      Removed value: -{
      -  "description": "Exactly one Admin 1 loc_id from resolve_point, such as USA-CA.",
      -  "minLength": 5,
      -  "type": "string"
      -}
    • addedInput schema / properties / family
      Added 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"
      +}
    • removedInput schema / properties / include_marine_context
      Removed value: -{
      -  "description": "Include parallel Marine overlaps. Defaults to true.",
      -  "type": "boolean"
      -}
    • addedInput schema / properties / shallow_loc_id
      Added value: +{
      +  "description": "The deepest canonical Admin 1-3 loc_id returned by resolve_point, such as USA-NY-061-009903.",
      +  "minLength": 5,
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "lat",
      -  "lon",
      -  "admin_1_loc_id"
      -]New value: +[
      +  "lat",
      +  "lon",
      +  "shallow_loc_id"
      +]
  3. Added

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description does not contradict this. It adds behavioral context by noting that shape-backed families use 'direct bbox-to-exact-shape lookup without crosswalks' and by describing the worldwide coverage baseline and country-specific deeper tiers. This goes beyond the annotation, providing useful insight into how the tool behaves across geographies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and usage, which is good. However, it includes a long 'Current catalog' paragraph that repeats boilerplate about coverage and country lists, which is tangential to direct tool invocation and could distract or be moved to get_catalog context. While not overly verbose, it contains non-essential content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters and no output schema, the description should specify the return value structure and any error/edge-case behavior. It does not describe the response format, whether it returns matching administrative tiers, point IDs, or other data. It also does not explain what happens when no match is found or when the shallow_loc_id is invalid. The description covers usage prerequisites well but leaves output behavior completely unaddressed, making it incomplete for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema: it clarifies that shallow_loc_id is 'the deepest canonical Admin 1-3 loc_id returned by resolve_point', points must be 'already known to fall within the supplied shallow_loc_id scope', and family defaults to administrative with examples like marine, postal_area, watershed. These additions help an agent understand parameter usage beyond raw field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('second-pass resolution') and resource (WGS84 coordinate or point array within a shallow_loc_id scope). It explicitly differentiates from resolve_point by requiring the shallow_loc_id returned by that first-pass tool, and references get_catalog for family selection. An agent can immediately understand what this tool does and how it differs from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly provides usage guidance by framing the tool as a second-pass step: 'Supply one shared shallow_loc_id returned by resolve_point and one canonical family from get_catalog'. It also explains the family default and the special case of shape-backed families. However, it does not explicitly state when NOT to use this tool or contrast it with resolve_point beyond the second-pass implication, leaving some ambiguity for edge cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.