Skip to main content
Glama

DaedalMap Disaster and Geospatial Data

by com.daedalmap
OverviewDiscussionsAdmin

Identify Geographic Reference System

identify_reference_system
Read-only

Free geography utility. Checks a bounded sample of identifiers plus optional dataset/column context against maintained reference indexes and geometry banks. LLM clients must extract identifier values from the user's natural-language request and pass them as strings; do not put the prose question in the arguments, and preserve leading zeros. Use it when a caller is unsure which system or level their keys belong to. It returns one to three interpretations with confidence and preserves ambiguity until the user confirms one by retrying with expected.system. A caller who already knows the system can provide expected on the first call and receive a verified geography_binding directly. It does not convert the full dataset or return polygons. No payment required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
expectedNo
identifierNoOne geography identifier to inspect.
request_idNoOptional caller-supplied request id for tracing.
identifiersNoA bounded representative identifier sample. Duplicate values are checked once. Values must be strings so leading zeros are preserved.
country_scopeNoOptional ISO3 country hint used to narrow candidate banks.
dataset_contextNoBounded, non-row dataset clues used to rank plausible interpretations without replacing exact identifier verification.
validation_scopeNoDescribes 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / validation_scope / description
      Previous 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."
  2. Changed2 schema fields changed
    • addedInput schema / properties / dataset_context
      Added value: +{
+  "additionalProperties": false,
+  "description": "Bounded, non-row dataset clues used to rank plausible interpretations without replacing exact identifier verification.",
+  "properties": {
+    "column_name": {
+      "type": "string"
+    },
+    "column_names": {
+      "items": {
+        "type": "string"
+      },
+      "maxItems": 1000,
+      "type": "array"
+    },
+    "file_name": {
+      "type": "string"
+    },
+    "local_format_match_rate": {
+      "maximum": 1,
+      "minimum": 0,
+      "type": "number"
+    },
+    "row_geography": {
+      "description": "Optional plain-language clue such as county, tract, or ZIP area.",
+      "type": "string"
+    },
+    "sheet_name": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
    • changedInput schema / properties / expected / properties / system / description
      Previous value: -"Expected reference system, such as us_census_geoid, loc_id, zcta, or a catalog reference system."New value: +"Caller-declared reference system, such as us_census_geoid, loc_id, zcta, or a catalog reference system. Supply it immediately when known, or after choosing an identification result."
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only provide readOnlyHint=true. The description adds meaningful behavioral detail: it returns one to three interpretations with confidence, preserves ambiguity until the user confirms with expected.system, and can return a verified geography_binding directly. It also discloses that it is free and that it does not convert the full dataset or return polygons, going well beyond the minimal read-only annotation.

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

Conciseness4/5

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

The description is moderately long but every sentence earns its place: purpose, usage condition, client instruction, output behavior, exclusions, and cost. The core scoping statement is front-loaded. It is slightly dense, but no section feels redundant.

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

Completeness4/5

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

Given there is no output schema, the description compensates by summarizing the return behavior (1-3 interpretations with confidence, verified geography_binding) and the key boundaries (no full conversion, no polygons). It could elaborate more on dataset_context and validation_scope behavior, but the schema already covers those parameters in detail, so the overall picture is complete.

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

Parameters4/5

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

Schema description coverage is 86%, so the baseline is 3. The description adds important parameter semantics not present in the schema: LLM clients must extract identifier values from natural language, pass them as strings, preserve leading zeros, and not include the prose question. This materially helps an agent invoke identifier and identifiers correctly.

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

Purpose5/5

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

The description states a specific verb+resource: 'Checks a bounded sample of identifiers ... against maintained reference indexes and geometry banks.' It also gives the exact scenario for use ('unsure which system or level their keys belong to') and explicitly distinguishes itself from conversion and geometry-returning tools, making it easy to separate from siblings such as convert_reference and get_geometry.

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

Usage Guidelines4/5

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

The description explicitly says 'Use it when a caller is unsure which system or level their keys belong to' and describes an alternative path for callers who already know the system (provide expected.system). It also gives when-not guidance ('does not convert the full dataset or return polygons'), but it does not name the specific sibling tools that handle those cases, so it stops short of fully explicit alternatives.

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

All DaedalMap Disaster and Geospatial Data toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources