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

There are no annotations, so the description must carry the full behavioral burden. It only mentions that the data comes from Open-Meteo, but it does not disclose that many of the input schema's parameters are unrelated to the weather lookup, whether authentication is needed, what the return shape is, or how failures are handled.

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: 'Current temperature for a city via Open-Meteo.' It is front-loaded with the core verb and resource, contains no filler, and is easy to scan.

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 is simple in concept, but the definition is incomplete for reliable invocation. There is no output schema, no mention of return units or response format, no statement that only 'city' matters, and no explanation of the many unrelated schema properties. An agent would struggle to know how to call this correctly and what to expect.

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?

The input schema already documents each parameter, so the baseline is neutral. The description adds value by clarifying that 'city' is the relevant input for the temperature lookup, but it does not state that the other parameters are irrelevant or ignored, and no parameters are marked required. The schema descriptions for ref, url, feed, host, json, and path suggest unrelated behavior, adding ambiguity.

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 and resource: returns the current temperature for a city, via the Open-Meteo provider. It is concise and clearly identifies the tool's core function, though it does not explicitly differentiate it from sibling hint tools or address the confusingly broad input schema.

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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or how it differs from sibling tools like geo-hint or lib-docs-hint, leaving the agent to infer usage solely from the name and one-liner.

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