echorune radar

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description earns credit by disclosing return-shape behavior that no output schema documents: a text radar map, an embedded PNG of the radar, and a phone-width PNG link, plus the explicit note that both text and images are intended to be consumed by a person or a model. It omits latency, rate limits, and failure behavior for unresolvable places.

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?

One dense sentence that front-loads the purpose before the output inventory, followed by a short sentence on the image payloads. Slightly overstuffed with parallel list items, and the closing clause about human-or-model readability is more marketing than specification, but nothing is genuinely wasted.

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?

For a two-parameter, read-only tool with no output schema, the description carries the return-value burden well by naming each content block and the image attachments. Remaining gaps are minor: no hint on response size, caching freshness, or behavior when a place name is ambiguous or a venue must be given as coordinates.

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 coverage is 100%, so both parameters are already documented, including the coordinate format and the landmark caveat. The description adds nothing parameter-specific beyond "any place on earth"; the lang enum and its default are left entirely to the schema. Baseline 3 applies.

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?

States a specific verb and resource ("Live weather for any place on earth") and then enumerates exactly what comes back: current conditions, air quality, short forecast, 2-hour rain sparkline, character radar map with echo motion, 24-hour and 5-day outlook. An agent knows precisely what this tool produces 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.

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

Usage is only implied by "Live weather" and "current conditions". No exclusions or alternatives are named (none exist among siblings), and there is no statement about what the tool will not answer, e.g. historical weather or climate normals. Adequate but leaves selection criteria to inference.

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