get_env_params

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

With no annotations, the description carries the disclosure burden and does meaningful work: it reveals the heatmap-matching requirement, that from_activity_id is free and supplies the date, that the two temperature inputs are mutually exclusive, and that omitting analysis returns every parameter. It stops short of describing error behavior or the response envelope, but covers the non-obvious constraints.

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?

Three sentences with no filler: the first states what the tool returns, the second states the core precondition and how to satisfy it, and the third explains response narrowing. Key constraints are front-loaded.

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 is strong on the temperature/activity path but leaves a notable gap: it says the temperature must match 'the same place and time' and that from_activity_id supplies the date, yet it never explains how to specify the time when using temperature= directly. With no output schema and no annotations, a mention of filter_type/start_date/start_time or the response structure would make it fully complete.

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 67%, and the description adds semantics beyond the schema: mutual exclusivity of temperature and from_activity_id, the date-providing role of from_activity_id, and the narrowing effect of analysis. It does not add meaning for wait_s or start_date/start_time, but the schema already documents the remaining core parameters.

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 opens with a concrete resource ('Environmental parameters at a single point - humidity, heat index, wet bulb, air quality and more') and a clear action (get). This distinguishes it from sibling submit/validate tools and makes the tool's purpose immediately actionable.

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?

It explicitly states the precondition (a temperature matching the heatmap), offers two mutually exclusive ways to satisfy it (temperature= or from_activity_id=), and explains when to omit analysis. It does not name alternative read tools such as get_result_slice, but the guidance for this tool's own options is specific and unambiguous.

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