Cosmic's Coast Map

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 a genuine behavioral constraint not carried by the annotations (or fully by the schema): results past 30 days require a pass key, which ties this tool to the coast_map_pass/pass_status siblings. It still says nothing about response shape, pagination, or whether results are empty outside coverage.

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 resource and lookahead window front-loaded and no filler. It could be tightened slightly ('over the next days' is a little vague about the window boundary).

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 only hints at the return ('marking the good ones') without saying how tides are scored or ranked. It also never addresses the location requirement (station code vs lat/lng) even though zero parameters are required, leaving the agent to work that out from the schema alone.

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 75%; lat, lng, and station are documented in the schema itself. The only real addition is for the undescribed 'days' parameter, and even that largely restates the schema's default=30 and maximum=90, with the pass-key caveat being the sole new information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and scope: the lowest daylight low tides over a lookahead window, with an explicit use case (clamming, foraging, tide pools). It is clearly distinguished from marine_forecast or currents by being about low tides, but it never names the closest sibling, tide_times, so an agent must infer the split itself.

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 implied through the activity framing ('for clamming, foraging and tide pools') and the lookahead default, but there is no explicit statement of when to choose this over tide_times, marine_forecast, or plan_paddle, and no exclusions.

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 safety is covered. The description adds useful content scope (benefits, pricing, sale state, links), but says nothing about freshness of pricing/sale data or whether links are the authoritative purchase path, which matters for an open-world info tool.

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 benefits, pricing, and sale status are front-loaded effectively. However, the trailing clause 'Covers offline use, longer tide ranges and upgrading' repeats content already stated in the first clause, adding length without new 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?

With no output schema, the description carries the burden of describing the returned content and does so thoroughly (what the pass adds, prices, sale status, links). The remaining gap is sibling routing, which is a usage issue rather than a completeness failure.

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, which is the baseline-4 case per the rubric. The description correctly describes a parameterless informational lookup and adds no misleading argument hints.

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 a concrete noun phrase and enumerates exactly what the tool surfaces: pass benefits, prices, sale status, and purchase/support links. It is clear what an agent gets, but it never names the overlapping siblings (pass_status, start_pass_purchase), so the boundary is left for the agent to infer.

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 by the content list (look here to learn about the pass and how to get it). With two adjacent siblings in the same family — pass_status and start_pass_purchase — the description gives no explicit when-to-use or when-not-to-use routing.

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?

readOnlyHint=true and openWorldHint=true already establish this as a safe external read, so the bar is lower, and the description adds real value on top: the free 7-day window versus the paid 90-day window via Coast Map Pass, and that results are returned in station-local time. It does not disclose pagination, error behavior for out-of-range stations, or what happens when a station has no predictions.

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

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

Two compact sentences with the core purpose front-loaded and the access-tier constraint second; 'in local time' is a high-value detail that earns its place. No filler or restatement of the 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 no output schema, the description carries the return-value burden and does so adequately by naming the three event types (slack, max flood, max ebb) plus speeds and local time. It is slightly thin on how the four optional location/day inputs interact (station vs lat/lng fallback) and on what an empty or out-of-coverage result looks like.

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 schema already documents lat/lng bounds, WGS84 convention, the days default of 2, the free/pass day limits, the 'from' format, and example station codes. The description adds nothing beyond the schema for any parameter, 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?

States a specific resource (slack water, maximum flood/ebb times and speeds at a current station) with the output units (local time), which is precise enough for an agent to distinguish it from tide_times. It never explicitly names the sibling tide_times or contrasts tidal currents with tidal heights, so differentiation is inferable rather than stated.

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 gives entitlement conditions ('Up to 7 days free; longer with a Coast Map Pass key') but no when-to-use guidance relative to tide_times or when a lat/lng lookup is preferable to a station code. It also omits the implied prerequisite that station codes come from find_stations, leaving that inference to the schema.

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 safety and open-world scope are covered. The description adds genuinely useful behavioral context beyond that: the geographic coverage footprint (Canada, US, Norway, Ireland, Netherlands, New Zealand, Queensland) and the modelled-versus-real distinction, which affects trust in results.

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 load-bearing: the first describes what is returned and what attributes accompany it, the second bounds where the data is valid. Front-loaded and free of 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?

With no output schema, the description does the right thing by naming the returned fields (distance, time zone, tide/current timings), and the coverage caveat is valuable. But it leaves the 'kind' filter and 'limit' behaviour unexplained, and 'distance' is unqualified as to units, so it is not fully sufficient for a 4-param discovery 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 50% — lat/lng are documented in the schema, but kind (enum) and limit carry no description anywhere. The description indirectly signals the tide/current distinction that the 'kind' enum encodes, but says nothing about the result cap (limit) or return-distance units, so it only partially compensates 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?

Specific verb+resource: it locates the nearest tide/current stations to a geographic point and enumerates what those stations expose (high/low times, slack water, max flood/ebb). That is clearly distinct from siblings like tide_times or currents, which retrieve readings rather than station locations, though the sibling distinction is left implicit.

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 implied by the shape of the tool (point-based proximity lookup), and the coverage list plus 'modelled tides elsewhere' tells the agent where results are authoritative versus approximate. However, there is no explicit statement of when to call this versus tide_times/currents, nor any exclusions or prerequisites.

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 and reach profile is covered. The description adds genuine value by disclosing temporal resolution (hourly), the 48-hour window and the upstream data sources (HRDPS/GDWPS, NWS, MET Norway), but says nothing about coverage gaps, caching, or how source selection behaves.

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, densely packed sentence that leads with the returned variables and front-loads the time window before listing data sources. No filler, though the source list at the end is the least essential element.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only lookup with no output schema, the description tells the agent what comes back, at what resolution, over what horizon, and from which providers. Minor gaps: no units for wave height/period and no handling of inland or out-of-coverage coordinates.

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% — both lat and lng are fully documented with ranges and WGS84 conventions — so the baseline of 3 applies. The description adds no further parameter meaning (e.g., whether land coordinates or coastal proximity matter).

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 (hourly wind, gusts, direction, temperature, rain, fog, thunder risk) with an explicit temporal scope (next 48 hours) and adds waves. This implicitly separates it from siblings like water_temperature, currents and tide_times, but it never names or contrasts an alternative directly.

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 48-hour hourly horizon implies when the tool is appropriate (short-range marine conditions), which is useful usage context. However, it gives no explicit when-to-use/when-not-to-use guidance and no pointers to sibling tools for other needs.

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 that the tool returns warnings currently in effect and lists example types (gale, storm, small craft), but does not disclose return format, freshness, or any other behavioral constraints beyond that.

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 a single, front-loaded sentence with no filler. It delivers the resource, scope, and example types efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with complete schema descriptions and annotations covering safety, the definition is nearly complete. It could optionally note how warnings are returned or when results may be empty, but no output schema exists, so return-value detail is not strictly required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for lat and lng, so parameter meaning is fully documented there. The description's phrase 'at a point' aligns with those parameters but adds no syntax, format, or constraint details 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 states a specific resource (marine warnings) and scope (for the marine forecast area at a point), with examples of warning types. It clearly differs from siblings like tides or water temperature, though it does not explicitly contrast with marine_forecast, leaving a minor ambiguity.

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 guidance on when to use this tool versus alternatives such as marine_forecast. The purpose implies retrieving active warnings for a point, but no when-to-use, exclusions, or alternatives are 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 cover openness and idempotency (openWorldHint, idempotentHint, destructiveHint=false), and the description adds real behavioral detail beyond them: the pending/paid state machine, a retry interval, the 'Authorization: Bearer <key>' usage convention after success, and an activation link. There is a mild tension between the read-only framing ('Checks whether...') and readOnlyHint=false, but the mention of a pass key and an activating link makes clear the call is not purely observational, so this is not a direct contradiction.

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 purpose and only two sentences, with no filler. The second sentence is densely packed (nesting the Bearer-header convention and the activation link inside the 'paid' case), which slightly hurts scannability but all content earns its place.

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 carrying the return values (pending with retry interval, paid with pass key, activation link) is necessary and it delivers. It leaves out failure/expiry states (e.g. what happens if payment never completes or fails) and any auth requirement, which are the remaining gaps for a polling 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% and the single parameter is fully documented in the schema, including its origin ('reference from start_pass_purchase (ag_…)'). The description repeats 'purchase reference' but adds no format or constraint 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?

The description states a specific verb and resource ('Checks whether the payment for a purchase reference has completed') and names the exact outcome states (pending / paid with pass key). Combined with the schema's pointer to start_pass_purchase, an agent can place this tool precisely at the end of the purchase flow and distinguish it from start_pass_purchase and the unrelated marine 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?

Usage is strongly implied: it is a post-payment status/collection step ('pending (with a retry interval)' signals polling after start_pass_purchase, and the title says 'after the user has paid'). The description never explicitly names start_pass_purchase as the prerequisite call or states when not to use it, so it stops short of full routing 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 cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds real value by enumerating what the response contains and by stating that heads_up lines are listed first — output-composition and ordering behavior the agent could not get from annotations, and there is no output schema to supply it.

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 sentence, front-loaded with the core promise ('One call that answers...'), and every clause enumerates a returned data type that would otherwise be undocumented. Slightly dense with nesting, but no sentence 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?

For a parameter-light, read-only aggregation tool with no output schema, the description successfully carries the burden of describing the return contents and ordering. It stops short of covering pagination, latency, or failure modes for a spot with no nearby station, which is the only notable 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%, so lat, lng and from are already documented with ranges, format (WGS84, YYYY-MM-DD) and the free-key 7-day limit. The description adds nothing about parameters, 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 a specific composite resource — tide station, currents, wind/gusts/waves, warnings, water temperature, sunrise/sunset for a given spot — so an agent understands this is the aggregated 'one launch' bundle rather than a single-domain tool. It is clear enough to separate from siblings like tide_times or marine_forecast, though it never names those siblings 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?

Usage is only implied via the title and the phrase 'One call', suggesting the agent should reach for this when it wants everything at once for a launch. There is no explicit statement of when to prefer the granular siblings (tide_times, currents, marine_forecast) or any exclusions, so the agent must infer the trade-off.

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, and the description reconciles with them by making clear no server-side payment occurs: the user pays in their browser and the reference identifies that payment afterward. It adds substantial context beyond the annotations (prices, currency, Stripe, no account required, fallback behaviour), though it does not say whether repeated calls mint multiple references or whether the reference expires.

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 tight sentences, front-loaded with the action and the return contract; the pricing/provisioning details are grouped in a parenthetical colon-list rather than padded into prose. Every clause earns its place.

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 zero parameters, no output schema and only coarse annotations, the description does the heavy lifting: it covers the return payload, pricing options, payment provider, authentication-free flow, and the negative outcome. An agent has enough to call it and explain the result without guessing.

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 no parameters, so the schema carries no semantic burden; baseline is 4. The description adds relevant context about what the caller receives (links, currency, billing cadence, purchase reference) without inventing parameter semantics.

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 (start/begin) and resource (Coast Map Pass purchase) and immediately describes what the call produces: checkout links tagged with a purchase reference, or a not-on-sale-yet signal. It is clearly distinguishable from siblings like coast_map_pass or pass_status, which do not initiate a purchase.

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?

Use context is implied (initiate a purchase from within the conversation, user completes payment in browser) but there is no explicit when-to-use versus when-not, and no pointer to siblings such as pass_status for checking an existing pass. The 'not on sale yet' fallback hints at a precondition without stating it.

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 readOnlyHint and openWorldHint; the description adds genuinely useful behavior not in the annotations — results are in the station's local time, include heights, and are gated at 7 days free vs 90 days with a Coast Map Pass key. It stops short of describing the return format or behavior when the key is missing/invalid.

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 tight sentences: the first front-loads what is returned, the second covers the access limits. Nothing is redundant and no filler is present.

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 5-parameter, no-required-args tool with no output schema and minimal annotations, the description covers output content (high/low times with heights), time basis, and access limits. The main gap is silence on return structure and on how lat/lng vs station is resolved when both or neither are supplied.

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 lat/lng, days, from, and station are already fully documented in the schema. The description reinforces the day-range and local-time semantics but adds no syntax or format detail beyond the structured fields — the baseline 3 for full schema coverage.

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 (high and low tide times) with the extra detail that heights and local-time framing are included. It reads clearly as the full tide-table tool, though it never names a sibling (e.g. best_low_tides) that an agent should consider instead.

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: the free/pass split tells the agent there are two access tiers but not when to prefer this tool over best_low_tides, currents, or water_temperature. No explicit when-to-use or when-not guidance is given.

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 genuinely non-obvious behavior: a nearest-buoy preference within a 40 km radius with silent fallback to satellite data, which tells the agent the result is a point estimate with resolution limits. It omits units, update cadence, and whether the fallback is surfaced in the response.

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?

One sentence, front-loaded with the primary data source and the fallback condition immediately after; nothing is redundant with the title or the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with annotations covering safety and openness, the description is close to sufficient. But with no output schema, it leaves the return contract unclear — units (Celsius/Fahrenheit), whether a timestamp or station identifier is returned, and how nulls over land are handled are all unstated.

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 both parameters carry WGS84 documentation, so the schema does the heavy lifting (baseline 3). The description adds only implicit meaning about how lat/lng are used (proximity search radius of 40 km), which sets precision expectations but adds 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?

Names a specific resource (water temperature / sea surface temperature) and, unusually, states the data source policy, so an agent understands what value it is actually getting. It does not, however, differentiate itself from nearby siblings such as `currents` or `marine_forecast`, which an agent may reasonably consider for the same coordinate.

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, no mention of alternatives among the many marine siblings, and no stated prerequisites or coordinate-domain constraints. The agent must infer that this is the right tool simply because the name matches the topic.

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