noaa_climate_data

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

Annotations already declare readOnlyHint=true, and the description's 'Get' aligns with this read-only nature. The description adds no behavioral context beyond the annotation (e.g., no mention of pagination, response size, API rate limits, or how to handle errors). The bar is lower with annotations, but there's still no extra transparency provided.

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 exactly two sentences: the first states what the tool does, and the second lists required and optional inputs. It is concise, front-loaded, and contains no unnecessary words or repetition.

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 tool with 7 parameters and no output schema, the description covers the essential usage pattern (required inputs and common filters). However, it does not mention how to discover valid dataset IDs (which noaa_datasets provides) or what the return structure looks like. A brief note on finding datasets or expected output format would make it more 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 description coverage is 100% for all 7 parameters, so the schema already explains dataset_id, start_date, end_date, station_id, etc. The description's mention of 'dataset ID + date range' and 'filter by station or location' reinforces required vs optional parameters but adds no new semantic detail beyond what the schema provides.

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 specifies the exact action ('Get climate observations') and the resource ('from NOAA'), with concrete data types (temperature, precipitation, snow, wind). It clearly distinguishes this tool from sibling tools like noaa_datasets and noaa_stations, which are metadata-focused, by focusing on the observation data itself.

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 explicitly states the required inputs (dataset ID + date range) and optional filters (station or location), providing clear context for when to use this tool. However, it does not explicitly direct users to related tools like noaa_datasets for finding dataset IDs or noaa_stations for finding station IDs, which would be a stronger exclusionary guide.

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