Skip to main content
Glama

Answer a plain-English question

ask
Read-onlyIdempotent

Answer a plain-English question about a US place or area in one step: plans it exactly as plan_question does, then runs the plan (point facts, nearest features, a parcel lookup, a parcel search or a geocode) and charges for that call. plan_question is the free, plan-only counterpart (0 lookups, nothing runs) that shows the tool, arguments and estimated cost first; the specific tools give finer control over fields and paging. Output: answer (a short deterministic summary), plan and the full result of the call made. When the plan needs a location or state that was not given, nothing runs and needs lists what is missing. Cost: metered exactly like the tool it calls (a geocode plan is free; a point-facts plan is 1 lookup per 50 fields); max_lookups refuses plans estimated above it, without charge. Behavior: read-only like plan_question, with the access, rate limits, timeouts and latency of the tool it calls; needs an API key or OAuth sign-in. Each ask makes one call, so a parcel search plan returns only its first page (25 parcels by default); parcel_search pages the rest. Errors: question_incomplete (see needs), over_budget (estimate above max_lookups), and any error of the tool it calls.

Input Schema

NameRequiredDescriptionDefault
latNoWGS84 latitude in decimal degrees (e.g. 30.2672), paired with lng. Optional: the place, when the question does not name it; lat+lng or address, not both.
lngNoWGS84 longitude in decimal degrees (e.g. -97.7431, negative in the US), paired with lat.
addressNoUS street address with city and state (e.g. '350 5th Ave, New York, NY'), geocoded by the US Census geocoder along the street. An alternative to lat+lng; giving both is an invalid_locator error.
questionYesThe question, 3 to 500 characters (e.g. 'nearest substation to 30.27, -97.74').
max_lookupsNoOptional budget: plans estimated above this many lookups are refused without charge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/open-world/idempotent, but the description goes well beyond: metered cost per call type (geocode free, point-facts 1 lookup per 50 fields), max_lookups refusal without charge, API key or OAuth requirement, inherited rate limits/timeouts/latency, one-call-only semantics limiting parcel search to page one, and named error codes (question_incomplete, over_budget). It also discloses the partial-success path where nothing runs and 'needs' lists missing inputs.

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 action and the plan_question contrast before cost and error details, and every clause is substantive. It is dense and long for a single paragraph, with some chaining and parentheticals that could be compressed, but no sentence is filler.

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?

For a metered, agent-orchestrating tool with no output schema, it covers everything an agent needs: what gets returned (answer, plan, full call result), cost model, budget behavior, auth, inherited limits, single-call page limitation, and error taxonomy. Nothing material is left to inference.

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

Parameters3/5

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

Schema description coverage is 100%, so lat/lng/address/question/max_lookups are already documented, including the lat+lng-vs-address exclusion and the invalid_locator error. The description mostly restates the max_lookups refusal rule already in the schema and gestures at the optional-locator case via 'needs', adding little new parameter meaning. Baseline 3 applies.

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 (answer a plain-English question about a US place/area in one step) and immediately pins down the mechanics: it plans like plan_question, then runs one of a named set of call types. It also names the siblings it is not (plan_question, the specific tools, parcel_search), so an agent can route without opening any schema.

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 frames plan_question as the free, plan-only alternative (0 lookups, nothing runs) and says the specific tools give finer control over fields and paging. It also names parcel_search as the paging escape hatch when the first 25-parcel page is insufficient. When-to-use and when-not are both spelled out.

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