noaa-cdo-mcp-server

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

Beyond annotations (readOnlyHint, openWorldHint), the description discloses the return format, the raw integer scaling issue, the proxy year for normals, and the effects of the units parameter. No contradictions 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 about 6 sentences, front-loading the main action and required parameters. It includes necessary details without redundancy. A slight trim could be made, but it's effectively structured.

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 parameters, 3 required, multiple dataset types, date constraints, output schema), the description covers all key aspects: return format, units behavior, dataset-specific limits, and the normals trick. It is thoroughly explained for an agent to use 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?

Schema coverage is 100% with all parameters described. The description adds extra context: re-emphasizes date limits, gives dataset examples, explains the proxy year, and recommends units. This adds value beyond the schema, justifying a score of 4.

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 fetches historical observation records from NOAA CDO datasets, specifying the action and resource. It distinguishes from sibling tools like noaa_find_stations and noaa_list_datasets by focusing on data retrieval, not discovery.

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 lists required parameters, optional filters, and date range limits per dataset type. It also recommends using the units parameter and clarifies the proxy year for normals. It does not explicitly mention when not to use this tool, but the context is sufficient for most use cases.

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?

The description goes beyond annotations by revealing the API's limitation (no name-search parameter) and the workaround (alphabetical sorting with pagination). It also provides concrete location ID formats, which aids understanding of the tool's output. Annotations already indicate readonly and open world; description complements them well.

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 concise and well-structured, with a clear logical flow: what it does, guidance for small vs large querysets, API limitations, and practical examples. Every sentence serves a purpose.

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 comprehensive for the tool's primary use case: retrieving location IDs for further use. It explains the most critical parameters (locationCategoryId, sortField) and provides workaround for the missing name search. However, some filter parameters (datasetId, datacategoryId) are not highlighted, though they are documented in the schema. Given the presence of an output schema, the description is sufficiently 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?

The description enriches parameter semantics by explaining the implications of locationCategoryId values (size estimates) and providing a strategy for finding specific names using sortField=name. This goes beyond the parameter descriptions in the schema, which only list options.

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's purpose: searching geographic locations by category and returning IDs for use in other NOAA tools. It provides specific examples of usage (states, cities) and explicitly names sibling tools, aiding differentiation.

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 clear context on when to use this tool (as a prerequisite for station/search queries) and gives detailed guidance on handling large result sets like cities (pagination, sortField=name). It does not explicitly state alternatives but ties into sibling tools, providing sufficient usage context.

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 and openWorldHint. The description adds behavioral context by specifying that returned station IDs are used as stationId in noaa_fetch_data and that a station must have data for the dataset and date range. This goes beyond what annotations 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 concise: four sentences that front-load the main purpose and return values. Every sentence adds value without redundancy or extraneous text.

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 (11 parameters, output schema, sibling tools), the description is complete. It covers the main query paths, explains how results connect to other tools, and provides filtering guidance. No gaps remain.

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 input schema has 100% coverage with descriptions for all 11 parameters. The description adds value by providing examples (e.g., 'FIPS:37' for NC, '47.5,-122.4,...' for Seattle) and notes on station ID formats. This enriches the schema information.

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 starts with a specific verb and resource ('Search for weather observation stations') and lists return fields. It distinguishes from sibling tools by mentioning that station IDs are used in noaa_fetch_data and locationId from noaa_find_locations, making its purpose clear.

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 explains when to use parameters like locationId, extent, datasetId, etc., and gives a concrete example for locationId. It implicitly advises filtering by datasetId and date range to ensure compatibility with noaa_fetch_data, providing good usage 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 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 declare readOnlyHint=true and openWorldHint=false. The description adds that there are approximately 41 categories, which is helpful context but does not go beyond the safety profile provided by annotations. 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?

Two compact sentences with the main purpose front-loaded. Every sentence adds value: lists examples, usage recommendation, and optional filters. 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?

For a simple list tool with an output schema and comprehensive input schema, the description gives the agent enough context to understand when to use it (discovery step) and what it returns (grouped data types). The mention of ~41 categories adds useful scope.

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?

Input schema has 100% coverage of parameters with descriptions. The description summarizes optional filters but adds no new meaning beyond the schema. Baseline score of 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 the tool lists data categories that group related data types like Temperature, Precipitation, etc. It explicitly distinguishes from the sibling tool noaa_list_data_types by indicating this is a precursor step to discover available measurements.

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 directly advises to 'use to discover what types of measurements are available before calling noaa_list_data_types,' providing a clear when-to-use context. It also notes optional filtering by dataset, location, station, or date range, helping the agent understand typical usage.

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 description doesn't need to restate that. The description adds value by stating the default returns all ~11 datasets and that filters are optional. It doesn't contradict annotations. However, it doesn't discuss rate limits or further restrictions, but given the read-only nature, this is acceptable.

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: the first states the purpose, the second explains default and filtering, the third gives examples and usage guidance. No unnecessary words; information is front-loaded and well-structured.

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 complexity (9 optional params, output schema present), the description covers the essential: purpose, default behavior, filtering options, common datasets, and recommended usage flow. It doesn't explain pagination details, but the schema covers limit/offset, and output schema likely describes return structure. Slight gap: no mention of the output schema's fields.

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?

Input schema covers 100% of parameters with descriptions. The description adds overall context that no parameters are required and optional filters exist, but it doesn't elaborate on parameter syntax beyond what the schema provides. Baseline from schema coverage is 3; the description provides minimal additional semantic value.

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 available NOAA CDO datasets with IDs, names, and temporal coverage. It differentiates from the sibling tool noaa_fetch_data by advising to use this first before fetching data, and mentions common datasets like GHCND and GSOM.

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 using this tool first before noaa_fetch_data, indicating it's a discovery step. It notes no required parameters and lists optional filters (datatype, location, station, date range). The mention of common datasets provides context for how results might look.

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 (safe read). The description adds that hundreds of types exist, implying pagination may be needed, and explains filtering options. 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?

Single, well-structured paragraph: first sentence states purpose, then explains filters, then gives usage guidance and examples. No wasted 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 complexity (10 optional params) and existence of an output schema, the description covers main use cases, mentions large number of types (implying pagination), and provides common type examples. 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 covers 100% of parameters with descriptions. The description adds value by explaining common usage patterns (e.g., using datasetId or datacategoryId) and listing example types, 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 'List available data types' and provides concrete examples like TMAX, TMIN, PRCP, SNOW, distinguishing it 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 using this tool before noaa_fetch_data when data type IDs are unknown, and gives common GHCND types as a reference. Does not explicitly state when not to use, but context is clear.

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