noaa-climate-mcp-server

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

Annotations indicate read-only and open-world. Description adds critical behavior: date limits, proxy year for normals, raw unit behavior without units parameter. 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?

Well-structured with key info front-loaded. Slightly verbose but each sentence adds unique value. Could be trimmer but reasonable for the complexity.

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 required params, optional filters, date range constraints, special cases (normals), and unit recommendations. Output schema exists, so return format mention is sufficient.

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 all params (100%), but description adds value: explains why units are recommended, clarifies date limits per dataset, and references sibling tools for finding station/datatype IDs.

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 ('Fetch') and resource ('historical observation records from a NOAA CDO dataset'), clearly distinguishing it from sibling tools that handle metadata or lookups.

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 detailed context on when to use (fetching data), date range limits per dataset, and special handling for normals. Does not explicitly state when not to use but implies alternatives through sibling mentions.

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 declare readOnlyHint and openWorldHint. The description adds context by explaining that there is no name-search parameter, the need for pagination, and the format of location IDs (e.g., FIPS:37, CITY:US530031). 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 well-structured: begins with purpose, then provides use-case-specific guidance, and ends with examples and downstream tool usage. Every sentence is informative, with no unnecessary repetition. It is concise yet comprehensive.

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 that an output schema exists (not shown but confirmed), the description is complete. It covers parameter usage, limitations (no name-search), and how to use the results. The tool is well-integrated into the context of sibling tools.

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 significant value: it explains the meaning of locationCategoryId values (ST, CITY, etc.), notes that CITY returns thousands of entries, and advises using sortField=name for alphabetical navigation. This goes beyond the schema's 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 clearly states the tool searches for geographic locations by category and returns location IDs used in station search and data queries. It distinguishes from sibling tools like noaa_climate_find_stations by specifying that this tool provides location IDs for subsequent queries.

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 explicit usage scenarios: how to list US states (locationCategoryId=ST), cities with pagination (locationCategoryId=CITY, sort by name), and advice on navigating the lack of a name-search parameter. It also explains where to use the results (pass to noaa_climate_find_stations or noaa_climate_fetch_data).

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 is consistent with annotations (readOnlyHint=true, openWorldHint=true). It adds practical behavioral context beyond annotations, such as the need to filter by dataset and date range to ensure stations have data, and the return fields. 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?

Extremely concise: two sentences in the first paragraph covering purpose and return values, followed by a second paragraph with practical usage advice and cross-tool relationships. No redundant information.

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 11 optional parameters, 100% schema coverage, and an output schema, the description covers all necessary context: what the tool does, how to filter, what it returns, and how the results connect to other tools. It is complete for an agent to decide when and how to use it.

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?

All 11 parameters are described in the schema (100% coverage), so baseline is 3. The description adds value by providing concrete examples (e.g., locationId 'FIPS:37' for NC, extent bounding box format for Seattle) and explaining their use in context, which goes beyond the schema's individual 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 clearly states the tool searches for weather observation stations by multiple criteria (location, bounding box, dataset, data type) and lists returned fields. It distinguishes from siblings by explicitly mentioning the use of station IDs in noaa_climate_fetch_data and location IDs from noaa_climate_find_locations.

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 clear guidance on when to use the tool (to find stations) and important usage advice: filter by datasetId and startDate/endDate to ensure data compatibility. It implicitly directs to noaa_climate_fetch_data for data retrieval, though no explicit 'when not to use' is stated.

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 adds value by detailing return fields (name, coordinates, elevation, date range). No information contradicts 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?

Two concise sentences: purpose with example, then usage guidance. No unnecessary words, highly efficient.

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?

Fully covers what the tool does, when to use it, and what it returns. Complete for a simple single-parameter tool with 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% with description for stationId. Description reinforces the example and adds context 'Obtain from noaa_climate_find_stations', enhancing understanding beyond 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?

States specific verb 'fetch', resource 'full metadata for a single weather station', and scope 'by ID'. Clearly distinguishes from sibling tool noaa_climate_find_stations which is for searching/finding 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?

Explicitly states when to use: when you have a station ID from noaa_climate_find_stations or to verify a station before querying data. Implies alternative tool for searching.

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 carries low burden. It adds no behavioral details beyond annotations, such as pagination behavior, rate limits, or any side effects. The mention of '42 categories in total' is factual but not behavioral.

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, no waste. First sentence states purpose and examples. Second sentence gives usage guidance and a key fact. Front-loaded and efficient.

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 read-only listing nature with no required parameters and an existing output schema, the description covers purpose, usage context, and available filters. It does not explain pagination (limit/offset) but those are documented in the schema. Slight gap could be mentioning total count is static, but overall sufficient.

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 9 parameters described in schema). Description adds a summary of optional filters ('by dataset, location, station, or date range') but does not provide additional meaning beyond what the schema already captures. 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?

Description clearly states the tool lists data categories, provides examples (Temperature, Precipitation, etc.), and explicitly distinguishes it from sibling noaa_climate_list_data_types by indicating it should be used before that tool.

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 says 'Use to discover what types of measurements are available before calling noaa_climate_list_data_types', giving a clear usage context. Lacks explicit 'when not to use' or alternatives beyond that one sibling, but the guidance is specific and helpful.

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 adds context beyond annotations: it specifies that by default all ~11 datasets are returned, that optional filters are available, and implies pagination via limit/offset. It does not contradict the readOnlyHint or openWorldHint 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 three sentences, front-loaded with purpose, followed by filter options and usage recommendation. Every sentence adds value, 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 tool's complexity (9 optional parameters, output schema present), the description covers purpose, filters, common datasets, and usage order. It is complete for an agent to understand when and how to use it.

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 some value by mentioning default for limit (25) and offset (0), and listing common datasets, but does not significantly enhance parameter understanding 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 it lists available NOAA CDO datasets with IDs, names, and temporal coverage. It mentions returning all ~11 datasets by default and optional filters, and distinguishes itself from sibling tools by advising to use it first before fetching 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?

The description advises to use this tool first to discover datasets before calling noaa_climate_fetch_data, and mentions optional filters. It does not explicitly state when not to use it, but provides clear context for 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 declare readOnlyHint=true, and description aligns with a read operation. Adds useful context: 'Hundreds of types exist across all datasets' and lists common GHCND types. No contradictions. Does not detail pagination or rate limits, but schema parameters cover limit/offset.

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 (4-5 sentences), front-loaded with purpose and examples. Every sentence adds 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 has 10 optional parameters and an output schema, the description covers the core use cases: filtering by dataset, category, dates, station, location. It mentions pagination implicitly via limit/offset. Sufficient for an AI agent to understand usage.

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 descriptions for each parameter. Description adds value by explaining how to use datasetId and datacategoryId with examples (e.g., 'TEMP'), and lists common types. This provides context 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 it lists data types like TMAX, TMIN, PRCP, SNOW for a given dataset or category. It distinguishes from sibling tools by mentioning noaa_climate_fetch_data and providing context for when to use this tool.

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 says 'Use this before calling noaa_climate_fetch_data when the data type IDs are unknown.' Provides guidance on passing datasetId or datacategoryId. Lacks explicit when-not-to-use or alternatives, but the context is sufficient.

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