Skip to main content
Glama

Geocode names in batch

geocode_batch
Read-onlyIdempotent

Geocode up to 20 free-text queries in one call, one best match each.

Instructions

Geocode up to 20 free-text queries in one call, one best match each.

Cuts N round-trips of geocode() into one and, more importantly,
shares ONE local divisions name table across the batch (#329) so a
two-name walk is not N cold S3 scans. For each query, keeps only
the top candidate.
Returns {"results": [{"query", "name", "type", "lat", "lon", "id"
(GERS), "rank_score"}, ...]}, one row per query, in input order — a
query with no match gets the standard error envelope {"query",
"error": "not_found", "detail"} instead, and does not fail the rest of
the batch. queries is capped at 20; a longer list returns a structured
{"error": ...} rather than truncating silently. Budgeted like every
other tool. Returns a structured {"error": ...} instead of raising if
the remote scan itself fails.

country (#457, ISO 3166-1 alpha-2, also accepting alpha-3 and aliases
like "UK"/"USA", case-insensitive) applies the same "City, Country"
constraint geocode() takes to every query in the batch — e.g.
`geocode_batch(["Cambridge", "London"], country="CA")` answers with
Ontario's London and a not_found row for Cambridge (no Canadian
Cambridge in the dataset), rather than the UK/US namesakes each query
would otherwise resolve to on its own. An unrecognized `country`, or a
per-query suffix that disagrees with it, returns a structured
{"error": "bad_request", ...} for the whole call.

Input Schema

NameRequiredDescriptionDefault
countryNo
queriesYes
limit_per_queryNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.0
    • addedInput schema / properties / country
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Country"
      +}
  2. First observedv0.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavior beyond them: per-query failure isolation (a not_found row does not fail the batch), the 20-query cap returning a structured error rather than silent truncation, remote-scan failure returning a structured error instead of raising, and the whole-call bad_request on country conflict. This is exactly the kind of context annotations cannot convey.

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?

Front-loads the core operation and the geocode() comparison in the first sentence, then layers error and country semantics in a logical order. It is longer than strictly needed, with internal issue tags (#329, #457) and slightly redundant restatements of the structured-error behavior, but nearly every sentence carries actionable information.

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

Completeness5/5

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 explained, yet the description still documents the per-row shape and the error envelope, and it fills in the cap, error-isolation, and country-constraint behavior that the schema and annotations leave open. For a batch tool with these annotations, nothing an agent needs to call it correctly is missing except limit_per_query.

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 coverage is 0%, so the description must compensate; it does so thoroughly for two of three params, specifying queries' cap and free-text nature and detailing country as ISO 3166-1 alpha-2 (also alpha-3, aliases like UK/USA, case-insensitive) with worked constraint semantics. However, limit_per_query (default 3) is never mentioned, and 'keeps only the top candidate' is in mild tension with a default of 3, leaving one param undocumented.

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 (geocode), a bounded resource (up to 20 free-text queries, one best match each), and distinguishes itself from the singular geocode() sibling by explaining the batch consolidation and shared local divisions name table. An agent can immediately tell it apart from geocode, resolve_place_batch, and reverse_geocode_batch.

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?

Explicitly frames the alternative (geocode()) and the condition that favors batch — N round-trips collapse to one call and share a single name table, avoiding N cold S3 scans. It stops short of stating an explicit when-not (e.g., a single query should stay with geocode), but the routing signal is strong.

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