noaa-cdo-mcp-server

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

Annotations declare readOnlyHint=true and openWorldHint=true, which the description aligns with ('Fetch'). Description adds behavioral details: return format as flat tuples, date range constraints, unit scaling behavior (e.g., TMAX=256 = 25.6°C without units), and proxy year for normals. No contradictions.

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 appropriately sized given 12 parameters and complex constraints. It front-loads the core action and constraints, then details optional scoping, date range limits, and units. Every sentence provides unique value, with no redundancy.

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?

Given the tool's complexity (12 params, 3 required), and that output schema exists, the description covers all key aspects: required parameters, optional filters, date range limits, unit handling, return format, and cross-reference to noaa_find_stations. Pagination is covered in schema, so no gap.

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?

With 100% schema coverage, baseline is 3. The description adds significant value beyond schema: explains date range limits per dataset type, special proxy year for normals, unit conversion details, and return format. Includes practical examples (e.g., 'GHCND:USC00450974', 'TMAX', 'FIPS:37').

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 clearly specifies the verb 'Fetch', the resource 'historical observation records from a NOAA CDO dataset', and includes key constraints (date range, datasetId). It distinguishes from sibling tools like noaa_find_stations and noaa_list_datasets by focusing on data retrieval from a given dataset.

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?

Provides explicit when-to-use guidance: requires datasetId, startDate, endDate; optional scoping to stations/locations/datatypeIds. Details date range limits per dataset type (1-year for daily, 10-year for monthly/annual) and special handling for NORMAL_* datasets. Strongly recommends units parameter. No exclusions needed, as this is the primary data-fetching tool.

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

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

Adds rich behavioral context beyond annotations: no name-search parameter, ID formats (FIPS, CITY:US530031, ZIP:98101, etc.), pagination recommendations, and that states are small (51) while cities are large. No contradiction with annotations (readOnlyHint, openWorldHint).

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 appropriately sized for a complex tool with 9 parameters. It is front-loaded with purpose, followed by specific usage strategies and examples. Every sentence adds value without redundancy.

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?

Given the tool's complexity (9 params, no required, output schema exists), the description covers all necessary aspects: purpose, usage, API limitations, ID formats, and integration with other tools. It explains everything an agent needs to invoke it correctly.

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?

With 100% schema coverage, the description still adds significant value: explains how to use locationCategoryId with specific examples and counts, and how sortField with sortOrder=asc enables alphabetical browsing. This goes beyond the schema's basic descriptions.

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 explicitly states 'Search for geographic locations by category' and specifies the resource as location IDs used in station search and data queries. It clearly differentiates from sibling tools like noaa_find_stations.

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?

Provides extensive usage guidance: when to use (to obtain location IDs), how to handle different categories (ST, CITY), pagination strategies, and how to chain with noaa_find_stations or noaa_fetch_data. It also explains the limitation of no name-search parameter and how to work around it.

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

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

Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds value by explaining the relationship to noaa_fetch_data and data coverage dates. No contradiction with annotations.

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 paragraph, front-loaded with purpose. It is efficient and avoids redundancy, though some sentences could be more concise.

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?

Given annotations (readOnly, openWorld), sibling tools, and output schema presence, the description is fully adequate. It covers usage, filtering tips, and cross-tool references.

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 baseline is 3. The description adds meaning beyond schema, e.g., explaining locationId format ('FIPS:37') and common station ID formats (GHCND:USC00450974).

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 uses specific verbs ('Search for weather observation stations') and lists outputs (IDs, names, coordinates, etc.). It distinguishes from sibling tool noaa_fetch_data by noting that station IDs returned here are used there.

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 context on when to use this tool: to find stations for subsequent data fetching. It advises filtering by dataset and date to ensure compatibility. However, it does not explicitly state when to avoid this tool or compare to noaa_get_station.

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

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

Annotations already declare readOnlyHint=true, so the description only needs to add details beyond that. It does so by specifying the return fields (name, coordinates, elevation, date range), which adds value beyond the annotation.

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 two sentences, both necessary and front-loaded with the action. No unnecessary words; first sentence states verb and resource, second gives usage context.

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?

Given the simple parameter structure, high schema coverage, existing annotations, and presence of an output schema, the description covers all necessary aspects: purpose, return values, and usage context.

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%, and the parameter description in the schema already includes the same examples and guidance. The tool description does not add significant extra meaning beyond what is in the schema, so baseline 3 is appropriate.

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 clearly states 'Fetch full metadata for a single weather station by its ID' with specific examples of station IDs, and distinguishes it from sibling tools like noaa_find_stations by mentioning when to use it.

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 tells when to use: 'Use when you have a station ID from noaa_find_stations and want its complete details, or to verify a station before querying data.' This gives clear context and implies not to use without prior station ID.

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

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

Annotations already indicate readOnlyHint=true, so the description's behavioral disclosure is minimal. It adds context about grouping and total categories but doesn't discuss pagination or response behavior.

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?

Two sentences deliver the essential information efficiently: what the tool does, examples, usage guidance, and total count. No superfluous words.

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?

Given the 9 optional parameters and existing output schema (not shown), the description is sufficient for an agent to understand the tool's purpose and when to use it. Could mention output structure, but that's covered by the output schema.

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%; all parameters are described in the schema. The description mentions optional filtering generically but doesn't add specific meaning beyond the schema.

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?

Description clearly states the verb 'list' and resource 'data categories', gives examples like Temperature and Precipitation, and notes the total count (42). It distinguishes itself from sibling tool noaa_list_data_types by stating its use as a precursor.

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?

Explicitly advises to use before calling noaa_list_data_types, with optional filters. While it doesn't provide exclusions or alternative scenarios, the guidance is clear and contextually appropriate.

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

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

Annotations already mark readOnlyHint=true; description adds that it returns all ~11 datasets by default and describes filtering. No contradiction, and the read-only nature is implicit in the listing operation.

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?

Two efficient sentences plus a list of common datasets. No unnecessary words, front-loaded with purpose and default behavior.

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?

Covers the tool's capability well. Output schema exists so return values are handled. Missing explicit mention of pagination (limit/offset) and sorting, but the schema covers these and the description doesn't need to duplicate.

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%, so baseline is 3. The description adds value by explaining filter options (e.g., 'datasets that contain a specific data type') and mentioning common datasets, going beyond the schema.

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 clearly states the tool lists NOAA CDO datasets with specific fields (IDs, names, temporal coverage). It uses the verb 'List' and specifies 'datasets' as the resource, and distinguishes from sibling tools like noaa_fetch_data.

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?

Explicitly advises to use this first before calling noaa_fetch_data. Lists common datasets for context. Does not exclude other tools, but provides clear when-to-use guidance.

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

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

Annotations already indicate readOnlyHint=true, so it's a read operation. The description adds context about hundreds of types and the data structure, which is helpful. However, it doesn't disclose any additional behavioral traits beyond what annotations and schema provide.

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 three sentences with embedded bullet-like examples. It is front-loaded with the action and efficient; every sentence adds value without redundancy.

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 10 optional parameters and an output schema, the description is nearly complete. It explains the purpose, usage, and common scenarios, though it could mention pagination or the output format briefly. Overall, it provides sufficient context.

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%, but the description adds value by explaining how to use parameters (e.g., pass datasetId or datacategoryId) and providing common type examples. This goes beyond what the schema offers.

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 clearly states the tool lists data types (measurement labels) for given datasets or categories, using specific verbs and resource references. It distinguishes itself from siblings by mentioning its use before noaa_fetch_data and providing examples like TMAX, TMIN.

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?

Explicitly states when to use the tool: before calling noaa_fetch_data when data type IDs are unknown. It also gives examples of common GHCND types, helping the agent understand typical outputs. No explicit alternatives, but context implies noaa_fetch_data as the downstream tool.

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