maps_geocodeConvert a location query into geographic coordinates. Use this to turn addresses or place names into latitude and longitude for mapping and spatial analysis.
Forward geocode (google with key, else nominatim).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.8.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description confirms a non-mutating operation. It adds the behavioral detail of provider fallback (Google if key available, otherwise Nominatim), which is useful context beyond annotations. No side effects or rate limits are disclosed, but read-only status is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It states the core action and a key behavioral detail (provider fallback) efficiently. Perfectly sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, has output schema), the description is mostly adequate. However, it lacks clarification on the query format and any limitations or prerequisites. The presence of an output schema reduces the need to describe returns, but the parameter ambiguity is a notable gap. Overall, it's minimally sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify the single 'query' parameter. The description only says 'Forward geocode' and implies the query is a location, but does not specify the expected format (e.g., address, place name) or provide examples. The schema title 'Query' is minimal, and the description adds no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Forward geocode') and the resource (geocoding). It clearly distinguishes from the sibling maps_directions by indicating a different operation. The provider fallback ('google with key, else nominatim') adds clarity without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. alternatives like maps_directions. The tool name and title make it clear it's for geocoding, but there's no mention of use cases or exclusions. The provider selection note is about implementation, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.