Skip to main content
Glama

Agent Data Tools: Everyday data

geocode

Find places by name in Wikidata (CC0) and get their coordinates, description, country, administrative region, population and elevation where recorded, best match first. Cities, towns, landmarks and other places with coordinates. Use before weather, sun or distance lookups, or to tell two places of the same name apart. Costs $0.001 in USDC on Base per successful call, paid with x402.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesPlace name
countNoMax results (1-10, default 5)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare openWorldHint and the safety flags, but the description adds genuinely new behavior: data provenance (Wikidata, CC0) and a precise cost model ($0.001 USDC on Base per successful call, paid via x402), which explains the non-read-only annotation. It stops short of covering failures (no-match, ambiguous names) or result ordering semantics.

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?

Three tight sentences, front-loaded with purpose, then usage, then cost. Every sentence carries distinct information and none can be dropped without losing value.

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?

With no output schema, the description compensates by listing exactly what is returned (coordinates, description, country, administrative region, population, elevation where recorded) and includes cost and sequencing guidance, so an agent has everything needed to call and interpret it.

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 both parameters are already documented in the schema, setting the baseline at 3. The description only indirectly touches parameters via 'best match first', adding no format or disambiguation detail (e.g., how to handle partial names) beyond the schema.

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 (find) plus resource (places by name in Wikidata), enumerates the returned fields, and specifies ordering ('best match first'). An agent can distinguish this from siblings like weather, sun, or wikipedia without opening the schema.

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?

Gives clear context ('Use before weather, sun or distance lookups') and a disambiguation use case ('tell two places of the same name apart'). It names downstream tools but does not frame them as alternatives or state any when-not-to-use condition, so it stops short of a 5.

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