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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful domain context by distinguishing API credits (daily point/area data) from bulk credits (point history), but says nothing about authentication requirements, whether counts update in real time, or what a depleted balance implies for subsequent calls.

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 compact sentence with the core concept ('Plan and remaining credits') front-loaded and the two credit categories immediately clarified. No wasted text, though the fragment style ('Plan and remaining credits:') is slightly telegraphic.

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 input parameters and no output schema, the description carries the burden of explaining return content. It identifies the fields conceptually (plan, API credits, bulk credits) but gives no sense of units, structure, or how to interpret a low balance against the request_* 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate 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 names the resource ('Plan and remaining credits') and enumerates the two credit pools it reports, so an agent knows exactly what information it yields. It lacks an explicit verb, but no sibling tool covers account/credit data, so differentiation is implicit and strong.

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 statement of when to call it or in what sequence relative to the request/download tools. An agent must infer that this is a pre-flight credit check rather than being told so.

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 safety profile is covered. The description adds useful context about what the link exposes (map, chart, CSV export), but says nothing about whether the URL is absolute, how long it stays valid, or that the call itself fetches no weather data.

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 front-loaded sentence with no filler. It is a noun phrase rather than a verb construction, which slightly undercuts immediacy, 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 an output schema present, return values needn't be explained, and annotations cover the read-only nature. However, for a 6-parameter URL-builder, the description never clarifies the link's intended consumer (human browser vs. embedding) or the start/end/time_scale consistency rule, leaving real gaps.

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 67%, and the description only loosely maps to parameters via 'location, variable and period'. It adds no semantics for the undocumented enum values (tmean/tmax/tmin/prcp, day/mon/ann) or for how start/end must align with time_scale, leaving the schema to carry that weight.

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 resource (a link) and states exactly what it resolves to: location, variable and period on the DailyMeteo map with chart and CSV export. It implicitly distinguishes itself from download/query siblings like download_gridded_files and request_point_history, though it never names them or says 'returns a URL' outright.

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 explicit when-to-use guidance or routing against the many siblings (get_weather, request_point_history, download_gridded_files, find_location). An agent must infer that this is the 'give a human a shareable interactive view' option rather than a data-returning 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?

Annotations declare non-read-only, idempotent, non-destructive and open-world, and the description adds genuinely new behavior: 1-3.5 GB per year of daily data, MD5 verification, and resumption of interrupted downloads. It doesn't say whether existing files are overwritten, where the files end up beyond the schema's dest_dir default, or what the tool returns, so it earns a 4 rather than a 5.

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 short paragraphs, front-loaded with the operation and its size/cost implication, followed by the safety-relevant resume behavior and the caller-side instruction. No sentence is filler.

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 six-parameter download tool with no output schema, the description covers cost, integrity checking, resumability and the required pre-step. The main remaining gap is what the call returns (file paths? manifest?), which matters for chaining a subsequent read, but the operational essentials are present.

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 83% and the schema already explains product, years, period, dest_dir and variable in detail; the description adds only the 'optionally unzip' framing, which is largely implied by the unzip boolean. Baseline 3 is the correct call when the schema carries the parameter burden.

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 (Download) and a named resource (MeteoEurope1km archives) with key attributes in the same breath: per-year archive size, MD5 verification, optional unzip. An agent can tell this apart from list_gridded_files, which it explicitly frames as the sizing/listing 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?

Gives a concrete workflow rule — call list_gridded_files and tell the user the total size before large downloads — which routes the agent to the right sibling at the right moment. It lacks explicit when-not guidance (e.g. point data should use get_weather instead of downloading archives), so it stops short of a 5.

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 description is not carrying the safety burden. It does add real behavioral facts beyond the annotations: the 3,000 km² area ceiling and the fact that the account balance is returned alongside the cost. It does not say what happens on exceeding the limit or whether estimation commits anything.

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 compact sentence with no filler, and the cost-plus-area scoping is front-loaded. It reads as a noun-phrase fragment rather than a full clause, which slightly weakens the leading statement but wastes nothing.

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 correctly names the two return values. However, for a 5-parameter tool it leaves the area-selection rules (bbox vs WKT vs neither), the meaning of variables, and the failure mode above 3,000 km² unexplained, which is not enough for confident invocation.

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 80%, so the baseline is 3. The description adds nothing on the bbox vs area_wkt choice (both default null, no stated mutual exclusivity or requirement) and nothing on the variables enum, leaving the biggest selection ambiguity to 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?

States a concrete verb-resource pair (credit cost estimate for daily rasters clipped to an area) and adds the account-balance return. It is clearly separable from request_area_download, but it never names that sibling, so differentiation is inferred rather than explicit.

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?

Usage is only implied: an agent can guess this is the pre-flight check before request_area_download, but no alternative is named and no when/when-not condition is stated. The 3,000 km² cap hints at a boundary but is framed as a limit, not as selection 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 and openWorldHint=true, so the safety profile is covered. The description usefully adds what the call yields (polygon + size), but says nothing about ambiguous name matches, not-found behavior, or size units — meaningful gaps for an open-world lookup.

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 tight clause with zero filler; the outputs and the downstream purpose are both front-loaded. Nothing could be removed without losing 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?

For a one-parameter read-only lookup with no output schema, the description covers the essential contract: input is an area name, output is a WKT polygon and its size, and it feeds the two area-download tools. Only edge-case behavior (no match, multiple matches, units) is absent.

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 the single 'query' parameter already carries an example ('Opština Brus', 'Lake Bled'). The description only restates 'named area', adding no new constraints such as expected granularity or matching rules, so the baseline 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?

The description names the concrete outputs (boundary polygon in WKT plus area size) for a named area, which is far more specific than the name 'find_area' alone. It also names the downstream consumers, distinguishing it from siblings like find_location or get_weather. It stops short of a clean verb+resource phrasing, reading as a noun phrase.

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?

'for estimate_area_download / request_area_download' implies this is a prerequisite lookup step before those tools, giving usable context. However, there is no explicit when-to-use/when-not guidance and no differentiation from find_location, the obvious alternative for resolving a place.

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 annotations already declare readOnlyHint and openWorldHint, so external-service behavior is partly covered. The description adds the data source and the multi-match/user-disambiguation behavior, which are genuinely beyond the annotations, but says nothing about rate limits, result ordering, or failure behavior for unmatched names.

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 short sentences with no filler. It front-loads the return value rather than the action, which is slightly backwards for tool selection, 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?

An output schema exists, so the description does not need to explain return values, and it covers the main risk (ambiguous matches) an agent must handle. The remaining gap is the undocumented limit parameter and whether results are ranked.

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 only 50%: query is documented with examples in the schema, but limit has no description anywhere. The phrase 'if several match' hints that multiple results can come back, which indirectly relates to limit, but the description never explains limit's range or effect.

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 the resource (coordinates of a place) and names the geocoding backend (OpenStreetMap Nominatim), so an agent knows exactly what it gets back. The verb is implicit rather than stated ('Latitude and longitude of a place' rather than 'Geocode a place name'), and it does not distinguish itself from the sibling find_area, which is likely the nearest alternative.

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?

It gives one concrete operational rule — 'If several match, ask the user which one' — which is real guidance for disambiguation. But it never says when to use this rather than find_area or when coordinates are a prerequisite for get_weather / request_point_history, so the choice among siblings 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.

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

Annotations only cover read-only and open-world; the description adds cost ('Free'), the derived change metric semantics, default expansion behavior when month is omitted, and prcp aggregation semantics. It does not say anything about response shape or rate/limits, so not a 5.

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 short sentences plus a one-word cost flag, all front-loaded; the earliest and most consequential caveats (month omission, annual prcp totals) come after the purpose, and nothing is filler.

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 6-parameter read with full schema coverage and no output schema, the description supplies the purpose, cost, and the two behavior traps most likely to cause misreads. It stops short of describing what a returned record contains for each time_scale, which would be the remaining 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 coverage is already 100%, so 3 is the floor; the description goes beyond it by explaining that omitting `month` with time_scale=mon returns all 12 months, and that annual precipitation is reported as a yearly total (units beyond the schema's °C/mm note). Day/ann interactions remain unstated.

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 the specific resource (climate normals) plus the two baselines covered and the derived change field ('newer minus older'), which is real information beyond the name. It does not distinguish itself from siblings like get_weather or request_point_history, so an agent must still infer when normals beat an actuals call.

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?

'Free' is a genuinely useful selection hint against paid/download siblings such as request_point_history or request_area_download, and the time_scale notes imply the intended granularity. But there is no explicit when-to-use or when-not-to-use statement and no sibling is named.

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?

Goes well beyond the readOnly/openWorld annotations by disclosing the cost model, the authentication prerequisite, the row-limit behavior (series over 400 rows are summarised by year and written to CSV rather than listed), and that results include a per-variable summary. These are exactly the facts an agent needs before spending credits.

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 sentences, each load-bearing, with the scope statement front-loaded and the cost/auth caveats following in the order an agent would need them. No filler or restatement of the tool name.

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 nine parameters and no output schema, the description does well to describe return shape (per-variable summary, CSV fallback for long series) and the paid-tier gate. It could say more about what happens when confirm_credits is required but false, but nothing essential to a correct call is missing.

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 already 100%, and the description still adds meaning: the cost formula ties directly to time_scale and variables, and the 1961 floor bounds start/dates. It stops short of explaining the confirm_credits threshold workflow beyond the schema's own text, so it sits modestly above baseline.

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?

Opens with a precise statement of what is returned: temporal resolution (daily/monthly/annual), a single location, one or more variables, and the 1961-to-present coverage window. That cleanly separates it from get_climate_normals and the file-download siblings, though no sibling is named explicitly.

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 concrete operational context for choosing this tool: monthly/annual is free, daily costs 1 credit per day per variable and requires an account or API key in server config. It does not explicitly say when to prefer this over request_point_history or get_climate_normals, so alternatives remain unaddressed.

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; the description adds genuinely non-obvious context — the data is free, hosted on an external service (Zenodo), GeoTIFF/COG format, Equi7 Europe EPSG:27704, Int16 scaled in tenths, NoData -9999. It does not disclose anything about the listing behavior itself: number of files returned, whether URLs or sizes are included, or whether results vary by product/variable combination.

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 short sentences with no filler; the dataset identity and geospatial/radiometric conventions are front-loaded. It is fragmentary rather than wasteful, though the second sentence is purely about raster decoding and slightly off-target for a listing tool.

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 say what the agent gets back from a 'list' call (file names, year coverage, URLs, sizes), and it does not. Four parameters with two enums and a required variable make the selection logic non-trivial, and the description leaves all of it to the 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%, so all four parameters (including enum meanings for product and variable) are already documented in the schema. The description only adds the unit context for the raster values (°C, mm, hPa, in tenths), which helps interpret variables but adds no parameter-level semantics 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?

The description identifies the resource precisely (MeteoEurope1km archives on Zenodo, Europe/1 km/1961-2020/COG) but never states the action — it never says it lists available archive files or what a returned entry contains. The verb 'list' exists only in the title and tool name, so an agent must infer that this returns a file catalog rather than metadata or a download link.

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 guidance on when to call this versus siblings such as download_gridded_files or estimate_area_download, nor any statement of prerequisites (e.g. that you must list before downloading). The only usage constraints live in the schema's parameter descriptions (years required for day/mon, period for normals), not in the description.

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 meaningful behavior beyond the annotations: the operation spends API credits, requires prior cost estimation plus user consent, is capped at 3,000 km², and results arrive asynchronously by email. Annotations (readOnly=false, idempotent=false, destructive=false) only tell the agent it is a non-repeatable write; the credit cost and email delivery are the valuable additions.

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 short sentences, both front-loaded: what the tool produces first, then the cost warning. Every clause carries decision-relevant information with no filler.

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 essentials for a 5-parameter, no-output-schema tool: what is produced, the area constraint, the cost prerequisite, and how the result reaches the user (email). It leaves minor gaps such as what the immediate response contains (confirmation or job reference) and expected turnaround.

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 80%, so bbox, area_wkt, start/end and variables are already documented in the schema. The description only contributes the 3,000 km² area limit tied to bbox/area_wkt and adds no guidance on which geometry parameter to use or how variables are chosen.

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 (daily GeoTIFF rasters clipped to an area), the size cap (max 3,000 km²), and the delivery mechanism (server-prepared, emailed). This clearly separates it from immediate-download siblings like download_gridded_files and from point-based request_point_history, though no sibling is named explicitly.

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 prerequisite workflow: run estimate_area_download first and obtain the user's agreement to the cost. That is concrete routing to a named alternative, but it does not say when to prefer this over request_point_history or how to choose between bbox and area_wkt.

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 carry readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is set. The description adds genuinely non-obvious behavior: it consumes one bulk credit that is billed separately from API credits, and file preparation takes minutes — both critical for an agent deciding whether to invoke it. It stops short of saying how the job is tracked or what happens if the email fails.

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, both front-loaded with the highest-value facts (scope and delivery first, then cost and latency). Nothing is padded and no sentence is redundant.

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 an asynchronous, email-delivered job with no output schema, the description covers what is produced, how it arrives, what it costs, and how long it takes. Remaining gap is failure/cancellation behavior and whether the call returns a tracking identifier, which an agent might want given idempotentHint=false.

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 latency/date semantics for start and end are fully documented there. The description's only addition — that the default span is the whole record back to 1961 — restates the schema defaults rather than extending them.

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 and resource — request the full daily point history for one location, delivered as CSV by email. The phrase "for one location" implicitly separates it from the area-oriented siblings (request_area_download, find_area) and from get_weather, though it never names a sibling explicitly.

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 "one location" scoping and the note that the default is the entire record since 1961 imply when this is the right call, but there is no explicit when-to-use vs request_area_download or estimate_area_download guidance, and no stated prerequisites or eligibility conditions.

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