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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'via Open-Meteo', implying a network call, but doesn't disclose that most parameters are discarded, that only certain inputs yield lat/long, or that the tool may behave differently for different inputs. The schema descriptions for parameters like 'city' ('discarded after the call') contradict the stated purpose of providing geocoordinates, so the description is misleading.

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?

The description is a single sentence, which is concise, but it omits essential details about usage and parameter mapping. It front-loads 'Latitude and longitude for a place' but adds little else; the phrase 'via Open-Meteo' is extraneous without context on how it relates to the inputs. It is under-specified rather than efficiently concise.

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?

The tool has 9 optional parameters, no required parameters, no output schema, and no annotations. The description gives no information about which parameters to supply, how to combine them, what the response format looks like, or error conditions. For a tool with this complexity and ambiguity, the description is grossly incomplete and insufficient for an agent to use correctly.

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 100%, so the schema documents each parameter, but the tool description adds no mapping between its stated purpose and any specific parameter. It doesn't clarify which parameter is the 'place' (e.g., city, query, or url). The schema descriptions themselves suggest this is a generic validation tool, not specifically geocoding, so the description fails to reconcile its purpose with the parameter set.

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 'Latitude and longitude for a place via Open-Meteo', which gives a general outcome but doesn't specify which input represents the place. The schema includes many unrelated parameters (ref, url, feed, json, etc.) with descriptions indicating they are discarded, creating ambiguity about the tool's true function. It also doesn't differentiate from sibling tools like weather-hint or tz-asia-yerevan.

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 guidance is provided on when to use geo-hint versus alternative tools. The description lacks any context about appropriate use cases, prerequisites, or conditions that would select this tool over its siblings. There is no mention of exclusions or alternatives.

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