Skip to main content
Glama

geocode_location

Find candidate places by name for weather and agricultural data, returning latitude, longitude, elevation, and timezone.

Instructions

Find candidate places by name.

Returns up to count candidates, where count is 1 through 10. Latitude and longitude are degrees, elevation is metres, and timezone is an IANA name. This tool has no date input and resolves the range to the current date. Example: geocode_location("Davis", "US", 3).

Input Schema

NameRequiredDescriptionDefault
nameYes
countNo
country_codeNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose useful behavior: a count of 1-10, units for latitude/longitude/elevation/timezone, and that no date input exists. However, the sentence 'resolves the range to the current date' is confusing and seemingly irrelevant for a geocoder, and nothing is said about no-match behavior or permissions.

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?

The definition is front-loaded with the purpose, followed by concrete constraints and a compact example. The 'no date input / current date' sentence is dead weight for this tool and slightly undermines an otherwise tight structure.

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

Completeness4/5

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

For a simple three-parameter tool with an output schema, the description supplies purpose, the count cap, return-unit conventions, and an example. The only real gap is the unexplained country_code behavior and the out-of-place date remark.

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 0%, so the description must compensate. It adds the count range (1-10) beyond the bare integer schema and demonstrates country_code via the example, but it never explains country_code semantics or the behavior when it is omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence 'Find candidate places by name' gives a specific verb and resource, making it unmistakably a forward-geocoding tool, distinct from the agronomic siblings. It lacks any explicit mention of siblings, but differentiation is obvious from the domain.

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

Usage Guidelines3/5

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

Usage is implied by the example call and by the nature of the tool (resolving a place name to coordinates), but there is no explicit statement of when to use it, prerequisites, or what to do when a name is ambiguous or unmatched.

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