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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds useful non-structured behavior — the database is community-built with beach-orientation/wind-direction knowledge, and failed lookups silently fall back to geocoding. It stops short of saying what happens when neither source resolves the name.

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 that front-loads the primary path (database) and appends the fallback, plus the routing directive. Every clause earns its place; nothing is repeated from the schema or annotations.

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 resolver whose safety profile is fully covered by annotations, the definition supplies the provenance of results and the resolution order. The only gap is that no output schema exists and the description never indicates what comes back (coordinates, canonical spot record, multiple matches), which matters for a lookup 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 the single 'query' parameter already carries examples ('Ouistreham', 'Tarifa Los Lances'). The description only restates the lookup-by-name semantics the schema already encodes, so baseline 3 applies — no syntax or matching-behavior detail is added.

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 — resolve a named spot in the 'windext spot database' — and discloses the two-stage resolution path (database lookup, then geocoding fallback). This cleanly separates it from sibling spot_info (detail for a known spot) because the description frames find_spot as the discovery step.

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?

'Always call this first' is an explicit, directive usage instruction that establishes ordering relative to spot_info and spot_forecast. It lacks an explicit when-not condition, but the escape hatch (geocoding fallback) is stated, so an agent knows it can rely on this tool even for names outside the database.

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, idempotentHint=true, and openWorldHint=false, so the agent knows this is a safe, deterministic read operation. The description adds that models are read 'by default' and mentions resolution/coverage notes, which is useful context beyond the annotations, but doesn't disclose any constraints on the location input or caching behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence with the core purpose front-loaded. No wasted words, though it could be slightly clearer on the action verb.

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 read-only, 2-param tool with no output schema, the description covers the core purpose and the locational dependency. However, with 0% schema coverage and no output schema, the agent has little detail on the exact return structure (model names, resolution format, coverage area units) or the expected lat/lon convention, leaving gaps for correct 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 description coverage is 0% and the schema provides only type and range constraints for lat/lon with no semantic descriptions. The description says models are read 'at a location' but doesn't explain that lat/lon are coordinates, their format, or coordinate system. It adds minimal meaning beyond the schema's constraints.

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 specific resource ('weather models windext reads by default') and what it returns ('resolution/coverage notes'). It's clear and distinguishable from siblings like find_spot or spot_forecast, though 'list_models' as a verb is somewhat passive.

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 phrase 'by default at a location' implies usage context tied to a lat/lon, but there is no explicit guidance on when to call this versus alternatives like spot_forecast. The agent must infer that this is for discovering default model configuration.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for disclosing domain behavior: multi-model consensus rather than a single forecast, daytime-only restriction, offshore exclusion, and forbidden-sector filtering unless allow_offshore is set. It stops short of describing result shape, timezone handling, or how consensus is computed.

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; the filtering constraints come in a logical order. It is dense but every clause (consensus, daytime, offshore, forbidden sectors, allowance) conveys a real constraint.

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 8-parameter, no-required-args, open-world tool with no output schema, the description identifies what a "window" is but not its format, units, timezone, or how many are returned. The parameter coverage gap and absent output schema leave meaningful questions unanswered.

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 25% (min_kn and spot_id documented), so the description must carry weight. It does map conceptually onto several parameters — "rider's range" to min_kn/max_kn, "offshore" to allow_offshore, "forbidden sectors" to facing_deg/spot orientation — but lat, lon, and days receive no clarification in either place.

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 concrete computed output — contiguous daytime windows where model-consensus wind falls inside the rider's range — which goes well beyond the tautological title. It implicitly differentiates from spot_forecast (raw forecast) by describing a filtered, derived result, though it never names the 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?

There is no statement of when to call this versus spot_forecast, tides, or spot_info, nor any prerequisites or exclusions. The agent must infer usage purely from the output 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?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety burden is lifted. The description then adds real value by describing what comes back (consensus, spread, agreement, gust factor, shore relation, plus a gust diagnosis), which matters since there is no output schema.

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, front-loaded with the core purpose, no filler. The long parenthetical model list is the only mild bloat, but it is genuinely informative for the models parameter.

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 adequately covers output shape for a no-output-schema tool, but with 10 parameters and only 60% schema coverage, several params (hours_from/hours_to, facing_deg, sport) get no description-level support and no usage routing is offered.

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 60% and the description reinforces the spot_id preference and names the model families, which loosely maps to the 'models' parameter. It does not clarify latency, days/hours_from/hours_to interactions, or the meaning of the remaining undocumented params, so it only partially compensates.

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 verb and resource ('Hourly wind forecast from several weather models at once') and details the output. It distinguishes itself substantively from generic forecast tools by naming the models and the consensus/spread/gust-factor framing, but never explicitly contrasts itself with siblings like ride_windows or list_models.

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?

Beyond 'Pass spot_id when known,' there is no guidance on when to choose this tool over ride_windows, tides, or list_models. The when/when-not framing is absent; the model-cost nuance lives in the schema, not 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds only what is returned ('full card', 'spots within a radius'), with no mention of error behavior, missing-spot handling, or result limits. Modest added value against an already-covered annotation set.

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 sentence with no filler, and the primary 'full card' case is front-loaded ahead of the secondary radius listing. It is arguably over-compressed, since 'known spot' and 'card' are never unpacked, but there is no wasted 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?

For a four-parameter, all-optional tool with no output schema and thin param docs, the description leaves major questions open: what a 'card' actually contains, and what a call with no spot_id and no coordinates returns. Given every parameter is optional, the default/no-argument behavior is a real gap that only the description could fill.

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 only 25% – lat, lon and radius_km carry no descriptions at all. The phrase 'within a radius of a point' loosely ties radius_km and the coordinate pair together, but says nothing about the 30km default, the 1-200 bounds, or that spot_id and coordinates are alternative modes. It does not compensate for the coverage gap.

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 (a spot) and two concrete retrieval modes: a full card for a known spot, or a listing of spots within a radius. An agent can infer this is a detail/lookup tool rather than a search or forecast tool. It stops short of explicitly distinguishing itself from siblings like find_spot or spot_forecast, so it is clear but not sibling-differentiated.

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' construction implies two usage modes but never states which inputs select which mode, nor when to prefer this tool over find_spot or spot_forecast. The useful routing hint ('preferred over raw coordinates') lives in the schema, not the description. No exclusions or alternatives are offered.

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 readOnly=false, idempotent=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely new behavior: cards enter status 'community' pending moderator verification, and corrections to verified spots are queued for review, plus licence/privacy terms. It does not explain how a 'correction' is matched to an existing spot, which matters given idempotentHint=true.

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 tight sentences, purpose front-loaded, then the gating rule, then moderation state and licensing. Every sentence carries information; the trailing 'Licence CC BY-SA, no personal data' fragment is terse but useful.

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 purpose, preconditions, moderation consequence and licensing, which is solid for a mutation tool. But with 18 params, no output schema and low schema coverage, gaps remain: how a correction is targeted (no ID parameter), duplicate handling, and what is returned on success or review-queueing.

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 adds zero parameter meaning for an 18-parameter tool. With schema description coverage only at 33%, the description was the place to explain the undocumented fields (season, rules, hazards, tide_notes, launch_notes, facing_source, country), and it does not.

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 ('Add a spot to the open windext database') and covers the dual mode ('or correct an existing one'). None of the siblings (find_spot, spot_info, spot_forecast, ride_windows, tides, list_models) perform writes, so an agent can route here without confusion, 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 a concrete precondition: 'Only call after the user has confirmed the facts.' That is real when-to-use guidance. It stops short of 5 because it never says to check for an existing spot first (find_spot) or when not to submit.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds important context: approximate accuracy (+/- 20 min), worldwide free availability, and that it returns empty for lakes. This goes beyond structured data, though it doesn't mention rate limits or exact return format.

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?

Four compact sentences front-load the core purpose, then caveats. Every sentence earns its place: model source, accuracy, constraints, and edge case. No redundancy or fluff.

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 adequately covers what is returned (times and heights relative to MSL). It notes limitations and edge cases. Missing information about required vs. optional parameters (none required) and whether lat/lon or spot_id alone suffices, but this is minor given the schema's clarity on types and defaults.

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 low (20%), with only spot_id annotated. The description does not explain lat/lon, days, or start_date semantics beyond what is implied. However, the schema itself provides types, ranges, and defaults for these parameters, so the baseline is 3. The description could clarify the interaction between spot_id and coordinates, which it only hints at via the schema note.

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 (tide high/low water times and heights) with a named data source (Open-Meteo marine model) and a clear scope (coastal spots). Distinguishes itself from siblings like spot_forecast by focusing on tidal data rather than general weather or spot info.

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?

Clearly indicates when to use (for tide times at a coastal spot) and implicit exclusions via 'not for navigation' and 'Empty for lakes'. No explicit alternative tool mentioned, but the niche is well-defined. Could name spot_forecast as a broader alternative for weather.

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