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

The description partially discloses behavior: it states that uncredentialed calls return a 402 payment envelope and that a signal is generated. However, it does not specify the output format (e.g., a probability, a recommendation, etc.) or what the 'best band-disjoint divergence' means in practice. The behavior is opaque regarding the actual signal result.

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 compact (one paragraph) and includes necessary operational details (cost, auth, parameter hint). However, its structure is dense and poorly organized, mixing technical specifications with usage notes. It could be more readable with clearer sectioning or plain-language explanations.

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 description gives some context (Polymarket, temperature markets, ~52 cities) and hints at usage (narrowing by city). Yet it lacks a high-level explanation of why a user would need this signal, how it fits into the broader set of tools, or when it is appropriate to call. The context is incomplete for a user unfamiliar with these specific markets.

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 schema declares no explicit properties, only allowing arbitrary string-valued parameters via additionalProperties. The description only hints at one parameter, 'city' (e.g., ?city=nyc), but does not document other potential parameters or their meanings. This leaves parameter semantics largely undefined and inconsistent with the schema's open-ended nature.

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 is highly technical with jargon like 'ladders', 'band-disjoint divergence', and 'met.no distribution', making it unclear to a general user what the tool actually does. It mentions 'daily temperature scan' and 'signal', but does not plainly state that it generates a prediction signal for Polymarket temperature markets.

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 provides some usage guidance: it mentions the optional 'city' parameter to narrow scope, the cost in credits, and authentication requirements (X-API-KEY or x402). However, it does not explain when to use this tool compared to sibling signal tools, nor does it describe typical use cases or expected input beyond a city.

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