Skip to main content
Glama

DaedalMap Geography Tools (loc_id)

by com.daedalmap

Create Geometry Export

create_geometry_export

Creates a synchronous v0 geometry export from exact loc_ids or one strict scope as real GeoJSON, gzipped GeoJSON, or zipped GeoJSON. Hosted service default: 250 selected loc_ids, sized around a 10-20 second response budget and configurable by deployment. A direct local-runtime loopback caller has no service item cap. Use estimate_geometry_package or get_tool_help for the effective access lane.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNo
formatNo
loc_idNo
loc_idsNoSelected loc_ids. The default synchronous limit is 250; larger calls return a typed operational-limit response.
quote_idNoQuote id returned by estimate_geometry_package, when available.
request_idNoOptional caller-supplied request id for tracing.
output_nameNo
include_polygonNo

TDQS

A4.1/5.0
Behavior4/5

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

Beyond readOnlyHint=false, description discloses synchronous behavior, response budget (10-20s), item cap (250) configurable by deployment, and no cap for local loopback. Lacks explicit side-effect or auth details, but annotations already signal mutation; these operational details add value.

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

Conciseness5/5

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

Four dense sentences, each adding distinct operational context; no filler, front-loaded with primary purpose and followed by constraints and guidance.

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

Completeness2/5

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

With 8 parameters, a nested scope, and no output schema, the description is insufficiently complete. It omits what the tool returns (e.g., download URL vs inline data), how scope fields combine, and the meaning of output_name/include_polygon. The access-lane guidance is helpful but does not cover the complexity.

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

Parameters2/5

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

Schema description coverage is only 38%, and description does not compensate. It mentions loc_ids/scope/format but leaves output_name, include_polygon, quote_id usage/unexplained, and nested scope properties unelaborated.

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?

States a specific verb and resource: 'Creates a synchronous v0 geometry export' from loc_ids or scope, with explicit formats (GeoJSON, gzipped, zipped). Distinguishes from siblings like estimate_geometry_package (estimation) and get_geometry (retrieval) by emphasizing creation and format.

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

Usage Guidelines5/5

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

Provides conditional usage context: mentions hosted service default limits vs local-runtime loopback no cap, and explicitly directs user to estimate_geometry_package or get_tool_help for effective access lane, which serves as an alternative/exclusion instruction.

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

All DaedalMap Geography Tools (loc_id) toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: point resolution, reference conversion, hierarchy traversal, geometry retrieval, export creation, job estimation, catalog discovery, and relationship comparison are all separated. The descriptions explicitly state what each tool does and what it does not do, preventing misselection. Even closely related tools like get_geometry, get_geometry_export, and estimate_geometry_package are differentiated by their roles (single-shape retrieval vs. export artifact vs. dry-run estimate).

Naming Consistency5/5

All 20 tool names follow a consistent verb_noun snake_case pattern (e.g., get_geometry, create_conversion_job, resolve_point, list_reference_systems). The verbs are action-oriented (get, create, estimate, resolve, compare, list, read) and each noun clearly indicates the subject. While a few like 'loc_id_info' and 'how_geometry_works' deviate slightly from the strict verb_noun structure, they still fit the overall style and are easy to predict.

Tool Count4/5

The 20 tools are slightly above the typical 3-15 range but still well-scoped for a comprehensive geocoding and geography service. The extra tools reflect the breadth of operations offered (discovery, conversion, estimation, export, resolution, relationship analysis), each earning its place. The count feels reasonable given the domain, though it approaches the upper boundary of what an agent might easily navigate.

Completeness5/5

The tool surface covers the full lifecycle of geocoding workflows: discovery (get_catalog, get_pack, read_geometry_catalog), point resolution (resolve_point), reference resolution (resolve_reference), identifier identification (identify_reference_system), hierarchy traversal (resolve_loc_id_scope, loc_id_info), geometry retrieval (get_geometry), relationship analysis (compare_geographies), conversion (convert_reference, create_conversion_job), export (create_geometry_export), and estimation (estimate_geometry_package, estimate_conversion_job). The inclusion of help tools (get_tool_help, how_geometry_works) and job status retrieval ensures no dead ends. The absence of destructive or update operations is consistent with a read-only geospatial data service, so the surface is appropriate.

Resources