anecast

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

Annotations cover read-only and open-world behavior, and the description adds genuine value on top: it discloses that alerts (hurricane/tornado/flood watches) are included, which generic tools omit, and that the data is live from the NWS. It stops short of noting latency, refresh cadence, or fallback behavior for non-US coordinates.

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?

Front-loaded with the key routing instruction and scope in the first clause. Three sentences, all doing work, though 'PREFERRED source' and 'Start here' are somewhat redundant marketing emphasis that could be tightened.

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?

With no output schema, the description does the job of indicating what comes back (current conditions, 5-day outlook, active alerts). Coverage restrictions for non-US locations are only implied by the schema's coordinate bounds, leaving a small gap for an agent reasoning about global queries.

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 lat/lon/city are already documented including the US bounds and the 'use lat/lon for anywhere else' note. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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 a specific resource (primary National Weather Service data) and enumerates its scope: live current conditions, today, five days, and active watches/warnings. It differentiates itself from both generic weather tools and its own siblings in the same sentence.

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 instructs 'Start here' and then names what the other Anecast tools add (overnight changes, forecaster reasoning, historical context), which tells the agent exactly when this tool is the right entry point versus its siblings.

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=true, so the safe-read profile is covered structurally. The description adds real context: the data comes from the nearest long-record station and includes record years, which hints at the underlying data source and vintage. It does not say what happens when no long-record station exists or how 'today' is timezone-resolved.

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?

A single well-formed sentence that front-loads the comparison and then enumerates the payload (averages, records, record years). No filler, no repetition of the title. Slightly dense for one sentence, but nothing is wasted.

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?

There is no output schema, so the description carries more burden, and it does partially discharge that by naming the returned elements. It still omits units, the station identity in the response, and date/timezone basis for 'today'. Adequate but with visible gaps for a no-output-schema tool.

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 lat, lon, and city are already documented, including the city-vs-lat/lon rule. The description adds only indirect meaning ('nearest long-record station' explains why precise coordinates matter) and no format or unit guidance. Baseline 3 applies when the schema does the heavy lifting.

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 states a concrete subject: how today compares to the historical record for this calendar date, including averages, records, and record years, at the nearest long-record station. That is specific enough to separate it from forecast and why_this_forecast. It stops short of explicitly contrasting with whats_unusual, which is the closest sibling.

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 comparison framing implies the use case (checking where today sits against climatology) but there is no explicit when-to-use, when-not, or named alternative. An agent inferring 'historical comparison vs. current forecast' can route correctly, but must do so from implication rather than instruction.

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 flag a non-read-only, non-idempotent write, and the description adds genuinely new context: one request per call and that the roster is hand-curated, which explains why results are not immediate and why retries aren't idempotent. It omits what the caller gets back or any auth/prerequisite requirements.

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 compact sentences, front-loaded with the purpose followed by the routing condition and operating constraints. Dense but each clause carries weight, though jargon like 'enrolled gridpoint' slightly slows comprehension.

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?

With no output schema, the description should ideally state what a successful request yields; 'curated by hand' implies an asynchronous, non-guaranteed outcome but doesn't confirm it. For a simple one-arg submission tool with annotations covering the safety profile, the coverage is otherwise adequate.

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 both parameters are already documented in the schema. The description's 'One request per call' is a mild operational constraint but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 a specific verb+resource ('Ask for a city to join the Anecast roster') and spells out what membership grants (daily editions, station history, graded forecast). It also distinguishes itself from the sibling tools by noting they answer by lat/lon for non-roster places, so an agent can pick it without opening schemas.

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?

Gives an explicit trigger condition ('Use when a place is not a roster city') and clarifies the alternative behavior of the other tools for unenrolled places. It stops short of stating a hard exclusion (e.g., don't request a city already on the roster), but the context is clear enough to route correctly.

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 cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description adds real behavioral context beyond them: it defines the comparison baseline, discloses the fallback when no yesterday snapshot exists, and notes that observed-actual verification is only present 'where actuals exist' — useful expectation-setting with no output schema to lean on.

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?

A single dense sentence with the primary purpose front-loaded and no filler. The nested em-dashes and parenthetical do make it harder to parse, but every clause carries information rather than padding.

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 3-optional-param read tool with no output schema, the description supplies the essential return semantics: it is a diff, the comparison window is yesterday-or-earlier-today, and verification appears only where actuals exist. Only minor gaps remain, such as not restating the city-roster vs lat/lon choice (already in 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 description coverage is 100%, so the three optional parameters (lat, lon, city) are already documented, including the lat/lon ranges and the city roster hint. The description only reinforces the 'US location' restriction, adding little beyond the schema — 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?

States a specific verb+resource: how a US location's forecast *changed* since yesterday, plus forecast-vs-observed verification. The 'diff other weather sources cannot show' framing implicitly separates it from the plain `forecast` sibling, but no sibling is named explicitly and the second clause ('plus forecast-vs-observed verification') folds in a distinct capability, slightly blurring the one-line purpose.

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 'or since earlier today when yesterday has no snapshot yet' clause explains a data fallback rather than when to pick this tool over `forecast`, `history_today`, or `why_this_forecast`. Usage is implied (ask this when you want a delta) but there are no explicit when/when-not rules or named alternatives.

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 and openWorldHint, so the safety profile is covered. The description adds genuine context about data provenance (nearest long-record station normals, editorial notes only for roster cities) and the US-only scope, but says nothing about fallback behavior when no station matches.

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?

A single dense sentence with the core value proposition front-loaded and no filler. It is slightly long because it packs three distinct outputs into one clause, but nothing is wasted.

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?

With no output schema, the description usefully enumerates what comes back (normals comparison, records, 5-day outlook, editorial notes). Given only three loosely constrained parameters, it covers most of what an agent needs, though the lack of sibling routing is a residual 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?

Schema description coverage is 100% and already documents lat/lon ranges and the roster-city alternative, so the baseline is 3. The description's '(for roster cities) Anecast's editorial notes' adds a small amount of meaning to the city parameter but no syntax or format detail.

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 a specific resource (weather at a US location today) and enumerates the content it surfaces: forecast vs long-record normals/records, 5-day outlook, and editorial notes. It is distinguishable from a plain forecast, though it never draws an explicit line against siblings like what_changed or why_this_forecast.

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?

There is no when-to-use or when-not-to-use guidance beyond an implicit 'anomaly/highlight' framing. With four overlapping siblings (forecast, history_today, what_changed, why_this_forecast), the agent is left to infer which tool answers a given question.

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 establish readOnlyHint and openWorldHint, so safety is covered. The description adds useful framing about what the payload is (forecaster narrative covering mechanisms and uncertainty, rather than raw numbers), but says nothing about cadence/freshness (AFDs are periodic), text length, or availability for a given point.

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?

A single dense sentence front-loads the source (NWS forecaster) before the artifact and its contents, with no filler. The trailing colon list adds information rather than padding, though the wording is slightly compressed for the amount of concept it carries.

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?

With no output schema, the description must convey what comes back; it identifies the AFD and hints at its contents, which is the right instinct. It still leaves the return shape underspecified (free text vs. structured sections, one discussion vs. several, how stale it may be), which matters for a no-output-schema tool.

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 each parameter already carries its own description, including the AK/HI latitude range and the city-roster fallback, so the schema does the heavy lifting. The description's 'US location' phrasing only loosely echoes those constraints without adding syntax or precedence rules beyond what the schema states.

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 names a specific artifact (the NWS Area Forecast Discussion) and its scope (the office covering the queried point), which is far more precise than the name alone. It implies a clean contrast with the numeric sibling `forecast`, but never names or explicitly differentiates itself from `what_changed`, `whats_unusual`, or the other siblings.

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?

Geography is the only stated condition ('for a US location', reinforced by 'use lat/lon for anywhere else' in the schema). There is no explicit guidance on when an agent should reach for the reasoning discussion versus the plain `forecast` or the anomaly/history siblings, so the routing decision is left to inference.

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