Skip to main content
Glama

Fetch the same facts for several locations

fetch_batch
Read-onlyIdempotent

Get the same preset and/or fields for several US locations in one synchronous call: the results come back in this response. Size: up to the plan's batch size (10 on Free, 100 on paid plans); fetch_location is the single-place form. More places than the batch size (up to 2000), or work that should not hold the call open, fit start_run with kind=batch, which is asynchronous: it returns a run id at once and get_run pages the results, at the same cost per location. Output: results index-aligned with locations, each with its own ok flag and either fields or an error, plus lookups_charged. One bad location does not fail the others. Cost: 1 lookup per location per started block of 50 delivered fields; locations with no data are free. Places not requested before are fetched live and can take a few seconds each. Behavior: read-only (no side effects); needs an API key or OAuth; each call counts toward the per-minute request limit (Free 10, Starter 60, Pro 300); one call is one request. Places run max_concurrent_locations at a time (Free 1, Starter 4, Pro 8), each waiting up to max_wait_s for slow sources; a place that waits over 20 s for a slot returns error busy (retryable). Lookups count toward the daily cap (Free 200, Starter 5000, Pro 25000). A repeat with the same idempotency_key within 24 h is free. Errors: whole-call errors as fetch_location (preset_unknown, fields_unknown, fields_too_many, no_fields_requested) and batch_too_large above the plan's batch size. Plan limits return rate_limited (with retry_after_s), daily_cap_reached or quota_exhausted.

Input Schema

NameRequiredDescriptionDefault
detailNocompact (default): value, unit, status, source and confidence per field. full: the complete record per field, adding license, attribution, vintage and notes. Same cost.compact
fieldsNoExact, case-sensitive field names from list_presets or search_fields (e.g. ['nfhl_flood_zone', 'elevation']). Combined with preset when both are given; up to 50 names that are not already in the preset. Unknown names fail the whole call with fields_unknown.
presetNoExact preset name from list_presets (e.g. 'flood_risk', 'terrain', 'solar_siting'). Its fields are added to fields; large presets cost more than 1 lookup (1 per 50 delivered fields).
locationsYes1 to 100 places (capped by the plan's batch size), each an object with lat+lng or address, exactly one of the two.
max_wait_sNoSeconds to wait for slow live sources before returning those fields as failed; default 10 s, capped at 15 s on Free and 30 s on paid plans. Optional.
idempotency_keyNoOptional 8-128 characters of letters, digits, _ or -. A retry with the same key and arguments within 24 h returns the stored result at no charge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/open-world, yet the description goes well beyond them: lookup-based cost model (1 per location per started block of 50 delivered fields, no-data locations free), per-plan request/concurrency/daily limits, live-fetch latency, the retryable 'busy' timeout path after 20 s, and free 24 h idempotent replay. This is the kind of operational context annotations cannot carry.

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?

Front-loading is good — purpose and size first, alternatives second, then output, cost, behavior, errors. But the whole definition is one dense paragraph that fuses cost, concurrency, timeout, quota and error taxonomy into a single unbroken block, which hurts scanability and makes some plan-limit detail feel like bulk rather than essentials.

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?

There is no output schema, and the description compensates by describing the return shape: results index-aligned with locations, per-item ok flag with either fields or an error, plus lookups_charged, and the partial-failure guarantee. It also enumerates whole-call error codes and distinguishes them from batch_too_large and plan-limit errors, leaving nothing an agent needs before calling.

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 100%, so the baseline is 3; the description still adds value by tying size to plan-dependent batch limits (10 Free / 100 paid) that the schema's static maxItems=100 cannot express, and by noting large presets cost more than 1 lookup. It does not add much on max_wait_s or idempotency_key beyond the already-detailed schema text.

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 ('Get the same preset and/or fields for several US locations in one synchronous call') and immediately scopes it as the multi-place form of fetch_location. The synchronous-vs-asynchronous split against start_run makes the distinction from siblings unambiguous.

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?

Explicitly routes three cases: this tool for up to the plan's batch size synchronously, fetch_location for a single place, and start_run with kind=batch for >batch size (up to 2000) or work that should not hold the call open. It even states the cost is the same, removing the last reason to guess.

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.

Resources