Gillby

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine unannotated traits: a hard cap of five spots, sampled-stops-only semantics, the exclusion of depth/bridge/zone checks, the unit conventions, and the presence of source/freshness metadata 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?

Three tight sentences, front-loaded with the primary capability, followed by scope exclusions then units. Every clause carries information; nothing is restated from the title 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?

No output schema exists, but the description discloses what comes back (conditions data plus source/freshness metadata), which is what the agent needs most for a nested-param read tool. The only residual gap is the exact encoding of the 'spots' string, which is neither in the schema nor fully resolved here.

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 single nested 'spots' string param is undocumented in the schema, so the description must compensate. It does add key meaning ('up to five ordered spot IDs'), but it never states the encoding of the string — separator, ID format, or how the 500-char maxLength maps to five spots — leaving real ambiguity for a 1-param tool.

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 ('Weather and marine conditions at up to five ordered spot IDs') and immediately scopes it against the adjacent capability ('does not create a navigable route'). An agent can distinguish this from plan_route/plan_my_route without opening the schema.

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 clear context (sampled stops, up to five, ordered) and explicit exclusions (no depth, bridges, zones, or conditions between stops), which tells the agent when this tool is the wrong choice. It never names the alternative tool by name, so routing relies on inference from the negative scope rather than an explicit 'use X instead'.

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, non-destructive, open-world behavior, so the bar is lower. The description adds real value beyond them: partial failures remain explicit, output units and direction convention, and that source/freshness metadata is returned.

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 that front-load purpose, then pack units, direction convention, and return shape. Nearly every clause earns its place, though the fragmentation 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 output schema, the description appropriately discloses return content (data plus source/freshness metadata) and unit conventions. Remaining gaps — behavior on more than five IDs and what 'verified' entails — are minor for a read-only comparison 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 0% and the single parameter is a nested object whose 'spots' field is only a bare string. The description compensates by explaining the format (comma-separated), the cap (five), and validation (verified IDs) — meaningful detail the schema lacks, though the handling of over-limit or unverified IDs is 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 a specific verb and resource with scope: 'Compare current conditions for up to five verified comma-separated spot IDs.' The multi-spot, bounded nature implicitly separates it from singular siblings like get_conditions and get_spot, though it never names them.

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 'up to five' and 'comma-separated spot IDs' constraints imply this is the multi-spot batch variant, but there is no explicit when-to-use guidance or exclusion against get_conditions/get_spot for single-spot lookups. Usage must be inferred from scope.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the consent requirement and the concrete repeated-delete response (deleted=false). The trailing 'Units... Returns data and source/freshness metadata' sentence is boilerplate that reads oddly for a delete operation and adds little.

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 first sentence is front-loaded and efficient, and the repeat-delete and consent lines earn their place. However, the appended units/return-metadata sentence appears to be shared template boilerplate that does not apply to a delete operation and dilutes an otherwise tight definition.

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 state the return shape ('data and source/freshness metadata') and the repeat-delete case, which is reasonable coverage. But the sole parameter is undocumented and the irrelevant units sentence creates noise, leaving the definition only minimally complete for the operation.

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 description never mentions the single nested parameter (path.id) or clarifies that it is the trip identifier. With one undocumented nested parameter and no compensating explanation, the description leaves the parameter meaning to inference from the tool name.

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 ('Delete a saved trip'), which is immediately distinguishable from siblings like delete_my_place, update_my_trip, and save_my_trip. An agent can tell exactly what this does without inspecting the schema.

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 prerequisite context (requires a Gillby account and explicit account consent) and a behavioral edge case (repeat deletes return deleted=false), which helps an agent decide when calling is appropriate. It stops short of naming alternatives or explicitly stating when not to use it, so it falls 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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, yet the description still adds real context: units (ft, kt, s, F, mi), 'directions FROM', a published-vs-live-data caveat, and that results include source/freshness metadata. This goes beyond what the annotations convey.

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 compact and front-loads the core search capability, but the misplaced 'Bridge data is published, not a live clearance calculation' sentence is irrelevant to anchorages and spends space without earning it.

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, and the description compensates by stating that results include source/freshness metadata, satisfying the return-value burden. Combined with the units/direction conventions and the published-data caveat, an agent has enough to call it correctly; the only shortfall is the undocumented limit parameter.

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%, so the description must carry the burden. It names the two query modes (name via q, bbox via west,south,east,north), which maps to the q and bbox fields, but the nested query object and the 'limit' parameter (default 20, max 100) are never explained, leaving meaningful gaps.

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 with the query modes: 'Search published anchorages by name or west,south,east,north bbox.' This distinguishes it from siblings like find_marinas, find_beaches, and find_dive_sites. The off-topic 'Bridge data is published' clause muddles the purpose slightly but does not obscure the core operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a caveat ('Verify access and operating details with the facility') but no guidance on when to choose find_anchorages over sibling discovery tools such as find_marinas or search_pois, and no exclusions or prerequisites. Usage context is left entirely 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 already declare readOnly/openWorld/idempotent/non-destructive, and the description adds genuinely extra context: the data is published rather than a live clearance calculation, and results carry source/freshness metadata. That freshness caveat is exactly the kind of behavioral detail annotations cannot convey. The stray bridge sentence is noise but does not contradict 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?

The operative sentence is front-loaded and short, but the definition is padded with two boilerplate lines: a bridge/clearance note that is irrelevant to a beach tool, and a unit/direction convention line. Roughly a third of the text does not serve this 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 does give some return-value context (data plus source/freshness metadata), but it never describes the shape or fields of a beach result, nor the limit/pagination behavior implied by the nested query object. Adequate but with clear 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 0% and the single top-level param nests q, bbox and limit, so the description must carry the load. It usefully defines the bbox ordering (west,south,east,north) and that search is by name, but never mentions the limit parameter or its default/max, leaving half the usable surface undocumented.

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 (search) and resource (published beaches) plus the two accepted lookup modes (name or west,south,east,north bbox), so an agent can distinguish it from find_anchorages, find_marinas, find_inlets and the other find_* siblings by resource alone. It does not explicitly name a sibling it is not, so it stops short of a 5.

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/when-not guidance and no alternative is named among the many find_* tools. "Verify access and operating details with the facility" is a disclaimer about data trustworthiness, not routing guidance for the agent.

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 readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds genuine behavioral context beyond that: data is 'published' (not live), users should verify access with the facility, and the response carries source/freshness metadata. The only blemish is the confusing 'bridge data...not a live clearance calculation' line, which reads as copy-paste noise for a ramp 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 description is compact and front-loads the search scope, and the units line is efficient shorthand. But the middle sentence about bridge clearance data is irrelevant to this tool and consumes budget without earning its place, hurting overall structure.

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's note about returning data plus source/freshness metadata is helpful. However, for a tool with a nested parameter object and 0% schema coverage, it omits pagination/limit behavior and the nested structure, leaving an agent to infer how to constrain result counts.

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%, so the description must carry parameter meaning. It does explain that search is by name ('q') or bbox and even gives the bbox ordering (west,south,east,north), which is real added value. But it never mentions the 'limit' parameter (default 20, max 100) or the nested 'query' wrapper, leaving one of three parameters undocumented.

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 first sentence states a specific verb and resource ('Search published boat ramps') with scope ('by name or west,south,east,north bbox'), which distinguishes it from nearby siblings like find_marinas or find_piers. However, the stray sentence about 'Bridge data' is irrelevant to boat ramps and muddies the otherwise clean statement of 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?

Usage is only implied — an agent can infer you call this to locate boat ramps by name or area. There is no explicit when-to-use or when-not, and no sibling alternative is named (contrast find_marinas, find_fuel_docks, etc. which all look similar).

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), but the description adds real value by disclosing that the data is a published snapshot rather than live, and that source/freshness metadata is returned. The irrelevant 'Bridge data' sentence detracts slightly but the provenance disclosure is genuine behavioral context.

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 units line and return-metadata note are tight and front-loadable, but the 'Bridge data is published, not a live clearance calculation' sentence does not earn its place in a dive-site tool and can actively mislead. One of the four sentences is wasted or wrong.

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 single-parameter search tool with no output schema, the units convention, bbox ordering, freshness caveat, and note that source metadata is returned give an agent nearly everything it needs. Only the undocumented 'limit' default/max and the unexplained bridge sentence leave 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 0%, so the description must compensate. It does so well for the bbox parameter by spelling out the axis order 'west,south,east,north' and by disambiguating the two query modes (name vs. bbox), though it does not explain 'limit' or the nested query object shape.

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 first sentence gives a specific verb and resource: 'Search published dive sites by name or west,south,east,north bbox,' which clearly separates it from siblings like find_wrecks and find_reefs. However, the stray sentence 'Bridge data is published, not a live clearance calculation' is copied from a bridge tool and muddies what this tool actually returns.

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?

'Verify access and operating details with the facility' is a useful caveat about how to treat results, implying this is a discovery step rather than authoritative clearance data. But there is no explicit when-to-use or when-not-to-use guidance and no named alternative among the many find_* POI 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description does add real context beyond them: the data is published rather than live, agents should confirm access/operating hours with the facility, and results carry source/freshness metadata. However, the stray sentence 'Bridge data is published, not a live clearance calculation' is boilerplate from a bridge tool and wrongly implies this tool returns bridge clearance data, muddying its 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?

Front-loaded with the core search behavior, which is good, but the irrelevant 'Bridge data...' sentence consumes space without earning it and the unit/metadata sentence is compressed to near-cryptic shorthand ('ft, kt, s, F, mi; directions FROM').

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, and the description only loosely characterizes the return ('data and source/freshness metadata'), omitting result shape and pagination behavior for the nested query object. Given annotations cover the safety profile and the tool has a single parameter, this is adequate but leaves 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 0%, so the description carries the burden and mostly delivers: it documents the name-search parameter and, crucially, the bbox ordering 'west,south,east,north', which the schema does not state, plus unit conventions. The 'limit' parameter remains undocumented outside its numeric bounds.

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 ('Search published fuel docks') plus the two query modes (name or bbox), so the agent knows exactly what it retrieves. It does not, however, differentiate itself from near-neighbor siblings such as find_marinas, which plausibly also surface fuel services.

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 or when-not-to-use guidance. 'Verify access and operating details with the facility' is a data-quality caveat rather than routing advice, and nothing tells the agent when to prefer this over find_marinas or search_pois.

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 the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuine value on top: data is published rather than live, and results carry source/freshness metadata — useful for an agent reasoning about staleness. The irrelevant bridge sentence is noise but not a 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?

The operation and filter syntax are front-loaded in one strong sentence, and the units line is compact. But the bridge/clearance sentence does not earn its place for an inlet-search tool and reads as leftover boilerplate, diluting an otherwise tight paragraph.

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 takes on return-value duty and does so adequately by naming 'data and source/freshness metadata' and the units. Combined with the facility-verification caveat, an agent has enough to call and interpret it, though the confusing bridge reference is a minor completeness risk.

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?

With 0% schema coverage and a nested query object, the description must carry the burden, and it does for the most part: it explains the bbox string as 'west,south,east,north' and q as a name filter, neither of which the schema documents. The 'limit' parameter is left unexplained, and the units/direction statement is only loosely tied to params.

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 ('Search') and resource ('published inlets') with the two supported filters (name, bbox). An agent can distinguish it from list_bridges or find_marinas by resource. However, the stray 'Bridge data is published, not a live clearance calculation' sentence muddies the purpose and suggests copy-paste from a bridge tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an important caveat ('Verify access and operating details with the facility') and disclaims live clearance applicability, which implies reconnaissance-only use. But it never states when to prefer this over the parallel find_* siblings (find_anchorages, find_marinas) or whether results are paginated, so the when/when-not guidance is only implied.

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/destructive/openWorld, so the safety profile is covered. The description adds genuine context beyond that: data is 'published, not a live clearance calculation,' the agent should verify details with the facility, and the response carries source/freshness metadata.

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 core search behavior is front-loaded in the first sentence, with caveats and units following. It is tightly sized, though the 'Bridge data' sentence reads as leftover context that is not clearly about marinas.

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 state what returns (data plus source/freshness metadata) and supplies a shared units legend. Coverage of query semantics is good, though the 'limit' parameter remains unexplained.

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 0%, so the description carries the burden. It usefully clarifies the bbox ordering (west,south,east,north) and the name-search mode, but never explains the 'limit' parameter or its defaults, leaving part of the nested schema undocumented.

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 (search) and resource (published marinas), plus the two query modes (name or bbox). It is clearly distinct from resource-specific siblings like find_anchorages or find_piers, but it never explicitly contrasts itself with them.

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 vs when-not-to-use guidance or named alternatives. The 'Verify access and operating details with the facility' caveat implies some care is needed, but it doesn't route the agent between this tool and the other find_* tools.

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, openWorld, non-destructive), so the description earns credit for adding that data is published rather than live and that responses carry source/freshness metadata. The instruction to verify operating details with the facility is a genuine operational caveat. It stops short of describing result limits or freshness semantics.

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?

Purpose and filter modes are front-loaded, which is good. But the bridge sentence is irrelevant to piers and the 'Units: ft, kt, s, F, mi; directions FROM' line is cryptic boilerplate that a caller cannot act on, so not every sentence 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 no output schema, no annotations gap, but 0% schema coverage and a nested object parameter, the description should do more: it omits the limit parameter and any sense of result shape or paging. It does cover units, metadata return, and the published-vs-live caveat, so it is adequate but incomplete.

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%, so the description must carry parameter meaning; it partially does by defining 'q' as a name search and 'bbox' as west,south,east,north. It never mentions the nested 'limit' parameter (default 20, max 100), leaving a real gap at low 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 verb ('Search') and resource ('published piers') plus the two filter modes (name or west,south,east,north bbox), which lets an agent distinguish it from find_marinas, find_anchorages, and the other find_* siblings. However, the sentence 'Bridge data is published, not a live clearance calculation' is off-topic for a piers tool and reads like boilerplate borrowed from a bridge tool, which blurs the stated 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 only guidance is a caveat to 'Verify access and operating details with the facility,' which is a disclaimer rather than usage routing. Nothing says when to pick find_piers over find_marinas, find_fuel_docks, or list_bridges, and no prerequisites or exclusions are 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 cover readOnly, idempotent, openWorld, non-destructive. The description adds genuinely new context: that results are published rather than live-calculated, that it returns source/freshness metadata, and the unit/direction conventions (ft, kt, s, F, mi; directions FROM). The off-topic 'Bridge data' clause is noise but does not contradict the safety annotations.

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

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

Front-loaded with the core purpose, then caveats, then units, which is sensible ordering. The 'Bridge data is published, not a live clearance calculation' sentence is irrelevant to a reef finder and does not earn its place, dragging down an otherwise efficient definition.

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, and the description partly compensates by noting it returns data plus source/freshness metadata along with unit conventions. The stray bridge/clearance sentence, however, risks misleading an agent about what this tool actually returns, leaving the definition short of fully self-contained.

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 0%, so the description must carry the load; it does clarify that the name filter maps to the string query and that bbox is west,south,east,north, which the schema does not state. It omits the limit parameter and its 1-100 range, so compensation is only partial.

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 opening sentence states a specific verb (search) and resource (published reefs) with two filter modes (name, bbox), which an agent can distinguish from find_anchorages/find_beaches/find_wrecks by resource name. It is clear, though it doesn't explicitly differentiate why an agent would pick this over a sibling finder. The trailing 'Bridge data' sentence muddies the resource slightly.

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?

'Verify access and operating details with the facility' and the freshness caveat imply this is reference/directory data rather than a live operational source. However, there is no explicit when-to-use statement and no routing to alternatives (e.g., get_poi, search_pois), leaving the agent to infer context.

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, openWorld, and non-destructive, so the safety profile is covered. The description adds a useful freshness caveat ('data is published, not a live clearance calculation') and mentions source/freshness metadata in the return, which are genuine behavioral traits beyond the annotations. The misplaced bridge sentence detracts but does not contradict the annotations.

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

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

The purpose is front-loaded and word count is low, but 'Bridge data is published, not a live clearance calculation' is irrelevant to a restaurant search, and the generic 'Units: ft, kt, s, F, mi; directions FROM' boilerplate does not apply to dining POIs, so not every sentence 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, and the description does note it returns data plus source/freshness metadata, and it partially covers the search inputs. But with 0% schema coverage it leaves limit and the nested query object unexplained, and it provides no usage routing, so it is only minimally complete.

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 0%, so the description carries the burden; it usefully explains that search is by name or a west,south,east,north bbox, giving meaning to q and bbox that the bare schema lacks. However it ignores the limit parameter and does not clarify the nested query object structure, 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?

States a clear verb (Search) and resource (published waterfront restaurants) plus the two search modes (by name or bbox), which differentiates it from the many find_* siblings by resource. It never explicitly names an alternative and the stray 'Bridge data is published' sentence introduces an off-topic concept that muddies an otherwise clear 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 only usage-ish guidance is 'Verify access and operating details with the facility,' which is a caveat rather than a when-to-use rule. There is no indication of when to prefer this over find_marinas, find_beaches, or other find_* tools, nor any prerequisite or exclusion.

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 read-only, open-world, idempotent, non-destructive behavior, so the bar is lower. The description adds useful context that the data is published rather than a live clearance calculation and that results include source/freshness metadata.

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 purpose is front-loaded and the caveats are brief. The sentence about bridge data is potentially irrelevant to wrecks and slightly confusing, but overall the description is compact.

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 and no parameter descriptions in the schema, the description should carry more detail. It covers the safety/published-data caveat and mentions source/freshness metadata, but omits limit behavior, pagination, and basic return shape.

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%, so the description must compensate. It usefully explains that q searches by name and that bbox is ordered west,south,east,north, but it says nothing about the limit parameter or result-size behavior.

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 ('Search published wrecks') and gives the two search modes (name or bbox). It does not explicitly differentiate itself from nearby siblings such as get_derelict_vessels or find_dive_sites, so it falls short of a 5.

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 implies usage through 'by name or ... bbox' and adds a caution to verify access details with the facility. However, it gives no explicit when-to-use/when-not-to-use guidance or named alternatives among the many find_* and get_* 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 cover the safety profile (readOnly, idempotent, open-world, non-destructive), so the bar is lower, and the description still adds real context: the 'unscored' handling of missing scores, the unit conventions (ft, kt, s, F, mi), that directions are FROM, and that source/freshness metadata comes back. These are behavioral traits not present in the annotations or 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?

Three short, front-loaded sentences with no filler; purpose leads and units/metadata follow. The telegraphic units sentence is dense but each line carries information an agent can act on.

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?

Safety is covered by annotations and, with no output schema, the description at least sketches the return shape (reasons, vetoes, metadata). But a nested three-property query with 0% schema coverage and a required spot identifier is only partially served; spot syntax and the activity enum are left to the schema and description alike.

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%, so the description must compensate. 'Hourly' hints at the hours parameter and 'activity scores' hints at the activity parameter, but the required spot parameter's format is never explained and the schema's hours default/range and the 13-value activity enum go unmentioned, leaving meaningful gaps.

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 and output: hourly published activity suitability scores with reasons and vetoes. An agent can tell it produces derived activity-suitability judgments rather than raw conditions, which distinguishes it from raw-metric siblings like get_wind or get_waves. However, it never names or contrasts a sibling (e.g. get_conditions, compare_spots, get_surf_forecast), so differentiation is 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?

No when-to-use guidance, prerequisites, or alternatives are given. The only conditional statement ('Missing activity scores are unscored') explains an output edge case, not how to choose this tool over get_conditions or get_forecast.

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, openWorld), and the description adds genuine behavioral context: explicit nulls when data is unavailable and returned source/freshness metadata. It does not state rate limits or failure modes, but it goes meaningfully beyond the annotations.

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

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

It is front-loaded and short, but the units sentence lists ft, kt and mi, which are irrelevant to an air-temperature tool and read as boilerplate carried over from a broader API. The water-temperature and visibility asides are useful disambiguation but dilute the core statement.

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 at least say it returns data plus source/freshness metadata and nulls. However, for a tool with a nested, undocumented query object and a required spot, it omits the parameter semantics an agent needs, leaving a real 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 0% and the nested object carries two parameters. The description only obliquely references 'a verified spot' and 'next hours'; it never explains the spot identifier format/required verification or the hours parameter (default 24, max 168). With no schema compensation, the agent is under-informed.

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 (air temperature) and scope (a verified spot, next hours), which is more than a restatement of the title. It does not explicitly name or exclude the obvious sibling get_water_temperature, though it alludes to water temperature only in a units aside.

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 use this tool versus alternatives such as get_water_temperature, get_conditions, or get_forecast. The phrase 'over the next hours' hints at a short-horizon forecast but gives no exclusions or 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 (readOnly, idempotent, non-destructive, openWorld), but the description adds genuinely useful context: the epistemic caveat that empty reports do not imply safe conditions, plus the fact that source and freshness metadata are returned. It does not disclose rate limits or dataset latency beyond 'freshness metadata'.

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?

Purpose is front-loaded and the safety caveat is well placed, but the units/directions sentence reads as boilerplate shared across many sibling tools rather than something specific to algae reports, weakening its earned value.

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 partially covers returns ('data and source/freshness metadata') and adds an important safety caveat, which is adequate for a read-only data tool. However, the complete absence of parameter guidance (bbox/category) for a nested-object query leaves a real 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 0% and the description never mentions the sole parameter (a nested query object with bbox and category). The unit line ('ft, kt, s, F, mi; directions FROM') is generic and does not explain how to filter spatially or by category, so it fails to compensate for the schema 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?

States a specific verb+resource: retrieving reported algae samples from a published agency dataset. An agent can distinguish it topically from siblings like get_red_tide, get_sargassum, and get_beach_bacteria, though it never names an alternative or explicitly delineates scope from them.

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 or when-not-to-use this tool versus the many sibling observation/water-quality tools. The only guidance is an interpretational caveat ('Empty reports do not establish safe conditions'), which governs reading results, not tool selection.

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 readOnly/idempotent/non-destructive/openWorld, so the description earns credit for adding interpretation rules: preserve original sample dates and unavailable states rather than interpolating, and treat satellite clarity as a relative index rather than measured dive visibility. Return-shape disclosure ('data and source/freshness metadata') is thin, keeping it at 4.

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 with the purpose front-loaded and no filler. The trailing units/directions line reads as family-level boilerplate (ft, kt, F, mi) that is only loosely tied to bacteria samples, a minor structural seam.

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 cover the essentials for a read-only sample lookup: scoping, caveats about missing/estimated data, and a one-line statement of what returns. Pagination or freshness-window detail is absent, but nothing critical is missing 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 single nested 'query.spot' property carries no prose, only a pattern and length bounds. The description partially compensates by specifying the spot must be 'verified', but it never explains the identifier format or the extra 'query' wrapper level.

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 (beach bacteria samples) scoped to a verified spot, which is clear enough to place it near get_algae_reports and get_red_tide. It does not explicitly differentiate itself from those sibling water-quality tools, so it lands at 4 rather than 5.

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?

No when-to-use guidance, no prerequisites, and no alternative named. 'For a verified spot' hints that the spot must already exist, but the agent gets no rule for choosing this tool over get_algae_reports or get_water_clarity.

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), and the description adds genuine behavioral context by disclosing that the return includes source/freshness metadata and that measurements are in ft/kt/s/F/mi with directions FROM. This is useful beyond the annotations, though it omits what happens when a boatId is not found.

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, front-loaded with the core purpose and followed by a compact units/return note. Efficient with no filler, though the units string is slightly jargon-dense.

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 single-record read with annotations covering safety, the description supplies units and return/freshness context, which is largely sufficient. The remaining gap is identifier sourcing for boatId, which is undocumented in both schema and description.

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?

With 1 parameter at 0% schema coverage, the description must compensate and does not. It never mentions the nested boatId, its allowed character pattern, or how the caller obtains a valid id (e.g., from list_boats).

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 single boat record 'from the library,' which adds some scope beyond the name get_boat, but it largely restates the title 'One boat's specs.' It never contrasts itself with siblings like list_boats (which would also come from the same library) or get_my_vessel, so the agent gets only an implied sense of the distinction.

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, when-not-to-use, or alternative routing guidance. Nothing tells the agent to prefer this over list_boats for a single vessel or how it relates to get_my_vessel.

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, open-world), yet the description adds real behavioral context beyond them: an LLM may be invoked on a cold cache (latency/cost), a template fallback exists, the source field can be claude/openai/template, and returned units/direction convention. It stops short of saying how long the cold path takes or how long results stay cached.

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 telegraphic sentences, front-loaded with the output shape, then fallback, source, rate limit, and units. Every sentence carries information, though the clipped phrasing ('Units: ft, kt, s, F, mi; directions FROM') is dense enough to be slightly harder to scan.

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 a single required parameter, no output schema, and annotations covering safety, the description supplies what is needed to call it correctly: what comes back, that a template fallback may occur, and the metadata accompanying the payload. Only the parameter's own semantics are left unaddressed.

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 reported at 0% and the description adds nothing about the spotId path parameter. However, the nested schema does carry a description ('Spot id, e.g. boca-inlet') and the parameter is self-evident from the title's 'for a spot', so the practical gap is small; 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 states precisely what the tool produces: 'a short headline + <=60-word body written from the live data', which distinguishes it from raw-data siblings like get_conditions, get_spot, or get_observations. It never names an alternative explicitly, but the synthesized-narrative nature of the output is unambiguous.

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 or when-not-to-use guidance, and no sibling is named as an alternative (e.g. 'use get_conditions for raw numbers'). The rate-limit note hints that this is a heavier call, but the agent must infer when a briefing is preferable to pulling the underlying datasets.

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, openWorld and non-destructive, so safety is covered. The description adds genuinely useful context beyond that: the payload is raw image bytes delivered through MCP rather than a browser fetch, and it carries a source timestamp. It does not discuss image staleness, caching, or failure modes for offline cameras.

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 with the core action front-loaded and the delivery mechanism second. 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?

No output schema exists, and the description does compensate by naming the return contents (JPEG bytes plus timestamp metadata). However, with an undocumented required parameter and no pointer to where camIds come from, it is not fully complete for a tool whose sole input is opaque.

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?

There is one parameter, camId, with a pattern constraint but 0% schema description coverage. The description never explains what a camId is or where to find one, leaving the only input undocumented in prose.

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 ('Fetch a public camera JPEG') plus what metadata accompanies it, so an agent knows exactly what comes back. It does not explicitly contrast with the sibling list_cams, which is the natural companion for discovering camera IDs, so it stops short of full sibling differentiation.

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 no when-to-use guidance, no prerequisites, and never mentions that list_cams is how an agent obtains a valid camId. The agent must infer the workflow entirely.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuine value beyond them: it declares the return includes source/freshness metadata and, critically, that an empty response must not be read as safe conditions — a non-obvious semantic warning.

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 purpose is front-loaded in the first sentence, followed by a caveat and a compact units line. It is tight overall, though the telegraphic units string ('Units: ft, kt, s, F, mi') is slightly cryptic without labeling which quantity uses which unit.

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 data-fetch tool with no output schema, the description partly covers returns (data plus source/freshness metadata) and supply units, which is helpful. However, the undocumented nested 'bbox'/'category' parameters and absent usage guidance leave clear gaps for a tool whose schema is entirely undescribed.

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 single nested 'query' parameter exposes 'bbox' and 'category' with no documented meaning, format, or accepted values anywhere. With coverage well under 50%, the description is expected to compensate but instead mentions no parameters at all, leaving them fully opaque.

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 (canal discharge and freshwater releases) and its provenance ('published agency dataset'), which no sibling covers, so an agent can distinguish it from the many get_* data tools. It stops short of naming which sibling to use instead (e.g., get_usgs_water or get_lake_okeechobee) for related freshwater/discharge data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus alternatives, no prerequisites, and no exclusions. The 'Empty reports do not establish safe conditions' line is an interpretation caveat for results, not usage guidance, so the agent gets no routing help.

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, openWorld), so the bar is lower. The description adds two useful facts beyond them: that results carry source/freshness metadata and that empty results are not evidence of safe conditions. However, the 'Units: ft, kt, s, F, mi' line is implausible for chlorophyll concentration and reads as template boilerplate, adding noise rather than clarity.

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 definition is short and the core purpose is front-loaded, which is good. But the units/directions sentence is irrelevant to chlorophyll and water color and does not earn its place, diluting an otherwise efficient description.

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 carry more of the return-value burden than the terse 'Returns data and source/freshness metadata.' It also leaves the nested query parameters (bbox, category) completely unexplained, which is a real gap for a geo-filtered data fetch.

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 single parameter is a nested query object with bbox and category, and schema description coverage is 0% — neither field is documented in the schema. The description does not mention bbox, category, expected bbox format, or any spatial/temporal scoping at all, so it fails to compensate for the total 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?

States a specific resource (satellite chlorophyll and water color) and its provenance (published agency dataset). It is distinguishable from siblings like get_algae_reports, get_red_tide, and get_water_clarity by naming chlorophyll/water color explicitly, though it never contrasts itself with those adjacent tools.

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 query this vs. get_algae_reports, get_water_clarity, or get_red_tide, and no prerequisites or conditions are given. The only guidance-like sentence, 'Empty reports do not establish safe conditions,' is an interpretation caveat rather than a routing rule, so the agent must infer usage on its own.

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), and the description goes well beyond them: explicit nulls when unavailable, source/freshness metadata, recorded-vs-reconstructed provenance, coverage/gaps, and a warning not to substitute wave/wind series for native chop. That is exactly the extra behavioral context the structured fields cannot supply.

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 purpose is good, but the body is dense and partly redundant – get_chop_history is named twice, and long imperative meta-warnings ('Never invent assistant-defined rough/calm thresholds...') read like prompt instructions rather than tool documentation. Several clauses could be tightened or dropped.

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 usefully enumerates what comes back (timestamp, source status, explicit nulls, freshness metadata) and warns against silent substitutions. Given a forecast tool with an openWorld source, this is nearly complete, though param semantics and the choice-vs-sibling story remain thin.

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%, so the description must carry the load. It implies the two nested params ('verified spot', 'next hours') and gives units for the returned values, but never explains the spot ID format/pattern, the hours default of 24, or its 1–168 range. Marginal compensation for a 0% coverage 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?

Names a specific resource (chop / boat-ride conditions) and scope (a verified spot, next hours), and explicitly distinguishes itself from get_chop_history. The phrasing 'Boat ride and chop' is a bit idiosyncratic, but an agent can tell what it returns versus the history sibling without opening the schema.

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 routes past-looking queries to get_chop_history with a verified spot ID, and states the temporal window ('over the next hours'). It does not say when NOT to use it versus the many other condition tools (get_waves, get_wind, get_conditions), so it stops short of full when/when-not 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 safe-read profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds real value: it states that recorded outputs and model reconstructions are identified separately, that coverage and gaps are preserved, that units are ft/kt/s/F/mi with directions FROM, and that source/freshness metadata is returned. The only thing missing is any hint of the record shape or pagination 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?

The units sentence is well-placed and front-loading the data scope is good, but the anti-fabrication warning is stated twice ("Never replace these with assistant-defined Calm/Moderate/Rough cutoffs" and "Never invent assistant-defined rough/calm thresholds"), and the self-referential "use get_chop_history" sentence earns no space.

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 is responsible for signaling return content, and it does so by promising data plus source/freshness metadata and provenance flags. It is complete enough to call the tool correctly, though it omits the record granularity and whether timezone defaults apply to the range.

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 is a nested query object, so the description must compensate. It does partially: "verified spot ID" clarifies the required spot key and "up to 31 days" bounds the from/to range, but the nested query wrapper and the default/format semantics of the optional date-time fields are left entirely 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?

The description names a specific verb+resource (native 0-10 chop series over up to 31 days with daily mean/max, coverage and 7-day trends) and its scope is unambiguous. However, it never distinguishes itself from the closely related siblings get_chop or get_history, so an agent must infer the current-vs-historical split on its own.

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 chop history or trends use get_chop_history with a verified spot ID" is essentially the tool's own name restated, so it adds little genuine routing guidance, and no alternative (get_chop for current conditions, get_history) is named. The precondition of a verified spot ID and the guardrail against substituting other series give partial context, so usage is implied rather than spelled out.

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. The description adds useful behavior (explicit nulls when unavailable, timestamp plus source/freshness metadata), but much of the text is boilerplate about water temperature, visibility and current-sign conventions that is irrelevant to cloud cover and dilutes the disclosure.

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 lead sentence is well front-loaded, but the middle sentences about water temperature, visibility and current conventions are template noise irrelevant to a cloud-cover tool, and the unit list ('ft, kt, s, F, mi') has little bearing on the stated output.

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 reasonably cover return shape ('timestamp, source status and explicit nulls', 'source/freshness metadata'). However, for a nested-object parameter with zero schema descriptions, the input contract is under-explained, so an agent lacks full detail on how to construct the query.

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%, so the description must carry parameter meaning, and it largely does not. 'A verified spot' and 'over the next hours' gesture at the spot and hours fields but give no detail on the spot-id pattern, the 1-168 hour bounds, or the 24h default that the schema already encodes numerically.

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 (cloud cover) scoped to 'a verified spot over the next hours', so the agent knows it returns a forecast. It does not name or distinguish itself from any sibling (e.g., get_forecast, get_conditions), leaving the boundary with related forecast tools to inference.

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/when-not guidance and no alternative tool is named. 'Over the next hours' weakly implies a short-horizon forecast, but nothing tells the agent why to pick this over get_forecast or get_conditions.

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, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: unit conventions (ft, kt, s, F, mi), that directions are FROM, and the important negative guarantee that empty reports do not imply safe conditions.

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, front-loaded with the resource identity, and no filler. The units line is dense and telegraphic but still earns its place for an observation 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?

The description notes it returns data plus source/freshness metadata, which partly substitutes for the absent output schema, and it flags the source attribution model. What is missing is routing guidance against the crowded field of sibling observation tools, which is the main gap for a zero-required-parameter read 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 0% for a nested query object containing bbox and category, and the description offers nothing about their format, accepted values, or semantics (e.g., bbox coordinate order, what categories exist). Neither the schema nor the description compensates, leaving the agent to guess.

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 (SECOORA coastal sensor observations) drawn from a published agency dataset, which is more distinctive than the generic siblings like get_observations or get_wind. However, it never explicitly contrasts itself with those sibling tools, so the agent must infer the boundary rather than being told it.

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 statement and no named alternative among the many overlapping observation siblings (get_observations, get_source_status, get_conditions). The line 'Empty reports do not establish safe conditions' is an interpretive caveat about results, not guidance on when to select this 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 already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description still adds real behavioral context: stale=false does not mean every source is usable, kiteboarding launch status is unverified and no overall kite score is implied, lightning is 'flashes observed' never a safety guarantee, and several interpretation traps (model sea height vs breaking surf height, MLLW gauges not establishing channel depth) are disclosed.

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 payload list is correctly front-loaded, but the text repeats itself: the kiteboarding paragraph appears twice and the activity-key list ('kite, surf, skim...') appears verbatim twice, adding no new information. Length is partly justified by tool complexity, yet those verbatim repeats are dead weight in an otherwise dense description.

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 and a nested query object, the description must describe what comes back, and it does: contents, units (ft, kt, s, F, mi, directions FROM), source/freshness metadata, and the caveats needed to interpret those returns. Nothing essential for correct invocation 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?

The counted schema coverage is 0% at the top level, so the description must carry parameter meaning, and it largely does: view=summary vs full, 'omit boat unless the user supplied or confirmed it', supplying kiteStyle/kiteExperience/kiteMinWindKt/kiteMaxWindKt, and 'never infer the rider wind range'. It adds rules the schema lacks, though the kite parameter block is duplicated rather than expanded.

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 specific verb+resource ('The full conditions bundle for a named spot') and enumerates every payload it returns (waves, wind, tide, scores, 7-day hourly, tides, windows, alerts, hazards, lightning, briefing). It also names a sibling it is not ('For an arbitrary lat/lon use get_point_conditions'), so an agent can separate it from get_point_conditions and the individual get_tides/get_hazards tools.

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?

Explicit routing: 'Start here for a current spot question with view=summary', 'Prefer view=summary unless you need every hour', 'Avoid duplicate hazard/tide calls unless a needed detail is absent', and the lat/lon alternative is named. Both when-to-use and when-not-to-use 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 already declare the read-only, idempotent, non-destructive, open-world profile, so the safety story is covered. The description adds real value beyond them: it discloses that returns include source/freshness metadata, states the units and 'directions FROM' convention, and warns that empty reports do not imply safe conditions.

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, front-loaded lines with no padding, and the dataset scope leads. The units line reads like a generic boilerplate blob (including kt, s, mi) whose relevance to a coral heat report is unclear, which costs a point.

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 state the return shape ('data and source/freshness metadata') and a key caveat, which is the minimum viable for a zero-required-param read tool. However, the nested query object is left wholly unexplained, leaving a real gap for an agent trying to filter results.

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 single nested query object (bbox, category) is entirely undocumented. The description supplies units (ft, kt, s, F, mi) but nothing about what bbox or category accept or how they scope the query, so the parameter burden is not met.

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: 'Coral heat stress and bleaching outlook from the published agency dataset'. The subject matter is distinctive among siblings (get_water_temperature, get_reefs, get_sargassum_outlook), so an agent can pick it out, though no sibling is named as an explicit contrast.

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?

No when-to-use guidance or alternatives are given. The only guidance-like sentence, 'Empty reports do not establish safe conditions', is an interpretation caveat rather than a selection rule, and nothing tells the agent when to prefer this over get_water_temperature or get_reefs.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them by disclosing explicit nulls when data is unavailable, source/freshness metadata, and the current-sign and unit conventions. These are the details an agent needs to interpret and trust the returned series.

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?

Purpose is front-loaded and the unit/convention notes are useful. Slightly dense and mildly redundant ('source status' vs 'source/freshness metadata'), but every sentence carries 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 supplies the return shape (data plus source/freshness metadata, timestamp, source status, explicit nulls), which is good. The gap is the undocumented 'hours' input for a nested-parameter tool, leaving forecast-window behavior unclear.

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%, so the description carries the burden: it clarifies that 'spot' must be a verified spot, adding meaning beyond the regex/maxLength constraints, but it never explains the 'hours' parameter (default 24, range 1-168) that defines the forecast window. Partial compensation only.

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 (predicted inlet currents) for a scoped subject (a verified spot over the next hours). No sibling tool covers inlet currents, so an agent can distinguish it from get_tides, get_gulf_stream or get_waves without opening a schema.

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 'for a verified spot' implies a prerequisite (the spot must already be verified), but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as get_tides for tidal height. Usage is only implied by the scope.

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, non-destructive behavior, so the safety profile is covered. The description adds that it distinguishes unavailable data and returns source/freshness metadata, which is useful context beyond annotations, though both claims are left vague.

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 lines, front-loaded with the purpose statement, with no padding. The units line is unexplained and arguably boilerplate, but nothing is bloated.

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?

No output schema and no parameters, so the description carries the burden of explaining what comes back. It does gesture at 'data and source/freshness metadata' and unavailable-data flags, but it never says what the inventory actually contains or what 'coverage' is measured over, leaving the return shape under-specified.

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 there is no parameter semantics to explain; the baseline of 4 applies. The units/directions note ('ft, kt, s, F, mi; directions FROM') is confusing here since nothing is being passed in.

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 (published dataset inventory plus verified spot coverage) but uses no clear verb and gives no differentiation from close siblings like get_dataset, list_datasets, and get_source_status. 'Distinguishes unavailable data' hints at a scope but doesn't tell an agent what distinct thing this tool produces versus those 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?

There is no statement of when to use this tool, no prerequisites, and no alternatives named. With three closely related siblings (get_dataset, list_datasets, get_source_status) in the list, the absence of routing guidance is a real gap.

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, openWorld, non-destructive), yet the description adds real behavioral context beyond them: a 503 error when the dataset has never loaded, the caveat that source-checked time is not observation time, that no records does not imply absence, and that the response carries source/freshness metadata. That is substantive disclosure the annotations do not carry.

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?

Purpose is front-loaded, but the body is bloated with repetitive and tangential caution text: the 'no records does not mean absent' caveat appears twice, 'not live beach warnings' appears twice, and lifeguard-link and NOAA Chesapeake-forecast warnings have no bearing on selecting or invoking this tool. Several sentences do not earn their 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?

For a nested-path tool with no output schema and 0% schema description coverage, the description covers error behavior, units, direction convention, and that freshness metadata is returned. It still leaves the required datasetId path parameter unexplained and gives no sense of the payload shape beyond 'data and source/freshness metadata,' so it is adequate but not complete.

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 0% for query params, so the description must compensate, and it largely does: category maps to USCG notices (e.g. bridge, hazard), homeZone limits to discharges, geometry includes MPA polygons. The bbox line ('bbox filters list datasets') is confusing and arguably points at a different tool, and the required path.datasetId is only implicitly explained via the list_datasets reference, which tempers the score.

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 opening sentence gives a specific verb+resource ('latest payload of one dataset') and anchors it to the sibling that produces the ID ('from list_datasets'), so an agent can place it in the workflow. It is marred only by the odd 'including sharks and jellyfish' framing, which narrows an apparently generic dataset fetch, but the core purpose is recoverable.

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 implies the usage pattern (fetch a dataset produced by list_datasets) and gives filter conditions for category ('USCG notices'), homeZone ('discharges'), and geometry ('MPA polygons'), plus a 503 condition. However, it never states when to prefer this tool over the many domain-specific siblings (get_shark_research, get_jellyfish_observations, get_red_tide), so routing guidance is only implied.

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, openWorld), and the description adds genuinely new behavioral context: the semantics of an empty result ('none were supplied, not a guarantee that every other hour is unsafe') and the fact that source/freshness metadata is returned. It still says nothing about pagination, window counts, or time-horizon limits.

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, each carrying distinct information, with the core function stated first. No filler, though the units sentence is a compact list that could be slightly better integrated.

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 correctly compensates by disclosing units and the presence of freshness metadata. However, with a nested required parameter and no explanation of 'spot', an agent cannot reliably construct a correct call from this definition 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 0% and the one parameter is a nested object whose required field is 'spot'. The description mentions activity filtering (the optional field) but never explains what a 'spot' identifier is, its format, or how to obtain one — the single most important thing an agent needs to call this tool.

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 ('published best windows filtered by activity'), and the word 'published' usefully tells the agent these are curated/served windows rather than computed on demand. It does not differentiate itself from close siblings such as get_activity_scores or get_forecast, so it stops short of a 5.

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 rather than get_activity_scores, get_forecast, or get_conditions, and no stated prerequisites for obtaining the required spot identifier. The empty-result caveat is about interpreting output, not about tool selection.

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 read-only/idempotent/safe, so the description earns credit for adding real caveats: unavailable/QC-failed sources must be reported even when freshness.stale=false, fresh does not mean every source is usable, and a point depth cannot prove route clearance. These are substantive limits beyond the annotation set, though they are tangled with unrelated tool guidance.

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 purpose sentence is front-loaded and final, but the body is a sprawling block that mixes units, kiteboarding, lightning, tide and surf guidance belonging to sibling tools. Large portions do not earn their place in this tool's definition and obscure the core behavior.

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 burden and does state it 'Returns data and source/freshness metadata' plus interpretation rules, which is adequate for a single-point lookup. It remains thin on what fields come back and on input param detail.

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 only parameter is a nested lat/lon object. The description adds the meaningful context that the coordinate must be a Florida point (matching the schema's 24-31 / -88--78 bounds), but it never describes lat/lon ordering or format, 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?

The opening sentence states a specific verb+resource ('Actual NOAA ENC chart depth and optional DEM depth at a Florida coordinate, with charted hazards, channel context and restriction zones'), so an agent can tell it is a point depth-plus-context lookup. It only implicitly differentiates from siblings via 'A point check does not prove clearance along a route,' which gestures at check_route_conditions without naming it.

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 one genuine routing hint: a point check does not prove route clearance, implying check_route_conditions for route work. The rest of the guidance ('for kitesurfing use get_conditions...', lightning phrasing, activity keys) is about OTHER tools and does not tell the agent when to use get_depth versus nearby lookups like get_hazards or find_anchorages.

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, openWorld, and non-destructive, so the safety profile is covered. The description adds meaningful context beyond that: it discloses source/freshness metadata in the return and warns that empty results are not evidence of safety, though it says nothing about latency, coverage limits, or data currency beyond 'availability.'

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, then a caution, then a compact units/metadata line. Nothing is redundant, though the units line is somewhat boilerplate relative to this tool's content.

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 mention of source and freshness metadata is a useful partial substitute, and the empty-report caveat is valuable. However, the nested bbox/category parameters remain completely unexplained, leaving an agent guessing at accepted formats and values.

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 single parameter is a nested object with bbox and category subfields that are entirely undocumented in both schema and description. The units line ('ft, kt, s, F, mi; directions FROM') describes data conventions, not what bbox format or category values are accepted.

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: 'Reported derelict vessels from the published agency dataset,' which is distinct from siblings like find_wrecks or get_hazards. It does not explicitly contrast itself with those closest siblings, so it stops short of a 5.

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 caveat 'Empty reports do not establish safe conditions' implies usage context (do not use absence as proof of safety), but there is no explicit when-to-use guidance or named alternatives such as find_wrecks, get_hazards, or get_navigation_notices.

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, and openWorldHint, so the safety profile is covered. The description adds useful context beyond annotations: source dataset, availability, empty-report caveat, return metadata, and units, though it omits rate limits or authentication needs.

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 with the purpose and caveat front-loaded; the units sentence is compact. No wasted words, though the units list is somewhat tangential to fish kills.

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 read-only retrieval tool, the description provides source and interpretive caveat but omits any explanation of the query parameters and gives only a vague return description ('data and source/freshness metadata'), insufficient for effective filtering.

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 description never mentions the bbox or category parameters, leaving their meaning and usage entirely unexplained. This fails to compensate for the lack of schema documentation.

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: 'Reported fish kills from the published agency dataset', making clear what data is retrieved. However, it does not explicitly differentiate from sibling data-retrieval tools like get_algae_reports or get_pollution_notices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides only a caveat about empty reports not establishing safe conditions, but offers no guidance on when to use this tool versus alternatives or any prerequisites for invocation.

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), yet the description adds substantial behavioral context the annotations cannot: freshness.stale=false does not mean every source is usable, QC-failed sources must still be reported, model sea height is not breaking surf height, high tide is not necessarily slack current, and lightning must be phrased as observed/not detected rather than a safety guarantee. These are real data-quality and output-interpretation behaviors, not restatements of the hints.

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?

Purpose is correctly front-loaded in the opening sentence, but the body is a dense block that mixes usage, interpretation rules, activity-key taxonomy and caveats without grouping, and the units line is stated twice ('ft, s, kt, deg FROM, F' then 'ft, kt, s, F, mi; directions FROM'). Content is mostly substantive but the repetition and lack of structure make it harder to scan than it needs to be.

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: hourly rows with tide/current and score reasons, 7 daily score rows, best windows, and source/freshness metadata. It also anticipates common misuse (per-activity fallback, unverified launch status, depth vs route clearance), leaving only finer return-field detail unspecified.

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?

Top-level schema description coverage is reported as 0%, so the description must carry weight, and it does: it defines units (ft, s, kt, deg FROM, F, mi), frames spot vs lat+lon as alternatives, and adds rules beyond the schema constraints such as 'omit boat unless the user supplied or confirmed it' and that kiteMinWindKt/kiteMaxWindKt are rider-supplied and never inferred. The nested properties do carry their own descriptions, which offsets the header-level 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 first sentence states a specific verb+resource (hourly forecast for a spot or lat+lon) and enumerates exactly what is returned: waves, swell/wind-wave split, wind, gusts, tide, current, precip/thunder, plus go/caution/nogo scores and daily rows. It also names a sibling and the condition that selects it (kitesurfing -> get_conditions with kiteStyle/kiteExperience), so an agent can place it against alternatives without opening the schema.

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 operating guidance (one call per spot for a time-window comparison, request only the hours needed) and routes kitesurfing to get_conditions, with a pointer to kiteboarding for screening. It stops short of explicitly contrasting this tool with close siblings such as compare_spots, get_activity_scores or get_surf_forecast, so it is clear context rather than full when/when-not coverage.

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, openWorld, non-destructive), so the bar is lower. The description still adds real value: it discloses that satellite clarity is a relative index rather than measured dive visibility, and that unavailable states must be preserved — genuine interpretive caveats beyond the structured fields.

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 purpose is front-loaded in the first sentence, followed by compact caveats and a units/return summary. Every sentence carries information, though the units string is dense and slightly list-like.

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 notes what is returned (data plus source/freshness metadata) and enumerates units and direction convention. The main gap is how an agent obtains a valid 'verified spot' identifier, which the sibling list_spots would supply.

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% for the single nested 'spot' parameter, so the description carries the burden. 'For a verified spot' hints the identifier must be validated, but no format, source, or lookup guidance is given to compensate for the total absence of schema descriptions.

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

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

States a specific verb and resource ('Approximate Gulf Stream edge') plus the required input scope ('for a verified spot'). It is clearly distinguishable from related siblings like get_currents or get_temperature_fronts, though it never names or contrasts with them 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?

There is no guidance on when to call this versus get_currents, get_water_clarity, or get_temperature_fronts. The note about preserving sample dates and unavailable states is output-interpretation advice, not a use-case or exclusion rule.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real behavioral context: it returns source and freshness metadata, QC-failed or unavailable sources must still be reported even when freshness.stale=false, and "fresh" does not imply every source is usable. It also fixes unit and direction conventions (ft, kt, s, F, mi; directions FROM). It does not describe response shape, auth or rate limits, so it is strong but not exhaustive.

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 content is front-loaded well (what it returns, then when to use it), but the middle is an undifferentiated block of interpretation rules spanning kitesurfing, skim/SUP scoring, offshore wind drift and anti-hallucination prohibitions ("Do not invent detection percentages, future readings, vessel ownership, or app settings instructions"). Several of these are model-behavior guardrails rather than tool-selection facts, and the run-on prose makes it hard to scan.

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 multi-source aggregation tool with no output schema and only one nested parameter, the description does the heavy lifting: it enumerates the covered hazard domains, states that data comes with source/freshness metadata, and flags interpretation traps (model sea height is not surf height, high tide is not slack current). What is missing is any sense of the returned structure or which sources may be 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?

The nested schema already documents lat, lon and spot, and the description adds only the input-mode hint "for a spot or lat+lon" plus an instruction to omit boat unless the user supplied or confirmed it. That boat reference has no matching schema property, which is mildly confusing, but the geographic-vs-spot choice is clear.

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 opening sentence names a specific resource (active NWS marine/coastal alerts plus water hazards) and enumerates exactly what it aggregates: rip current risk, red tide, bacteria, sargassum, water clarity, king tide, Gulf Stream distance, lightning. That enumeration lets an agent distinguish this composite hazard tool from the single-hazard siblings (get_marine_alerts, get_rip_risk, get_red_tide, get_lightning) without opening any schema. Scope (a spot or lat+lon) is stated immediately.

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 an explicit trigger - "Use before recommending swimming, diving or running an inlet" - and names an alternative for one case: kitesurfing should go to get_conditions with kiteStyle/kiteExperience instead. It stops short of a full when/when-not map (e.g. it never says to use get_marine_alerts directly for alert-only lookups), so it is clear context without complete 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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real value beyond that: the status enum (ok|degraded|down), the HTTP 503-only-when-down mapping, and that source/freshness metadata is returned.

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 health content is front-loaded and tight, but the trailing 'Units: ft, kt, s, F, mi; directions FROM' line is boilerplate that is irrelevant to a health endpoint and does not earn 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?

For a zero-required-param diagnostic tool with no output schema, the description covers the return shape well enough (status enum, HTTP behavior, metadata presence, detail expansion). Return-value specifics remain vague, but no output schema exists to offload them.

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 0% and the single nested param (detail, boolean) is undocumented in the schema. The description compensates by stating 'detail=true lists every source', which is exactly what an agent needs to choose a value.

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 (ingest worker heartbeat, feed-family staleness, government dataset status, GLM lightning) and a concrete verb (rolls up). It is clearly a health/diagnostic tool, though it never explicitly distinguishes itself from the closely related sibling get_source_status.

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?

'Check this before trusting no data from other tools' gives explicit, actionable when-to-use guidance and the detail=true note clarifies the expanded mode. It lacks any when-not guidance or a direct comparison to get_source_status/get_data_coverage, which are the nearest 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, idempotentHint, openWorldHint, and destructiveHint=false. The description adds substantial behavior beyond those annotations: maximum 31-day window, up to 1000 points, latest revision/run wins, rejected and suspect rows are excluded, unreviewed rows retain quality metadata, provenance preservation, unit conventions, and returned freshness metadata. No contradiction with annotations is present.

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 purpose is front-loaded in the first sentence, and each subsequent sentence adds routing, constraints, provenance rules, or units. However, the description is dense and includes several prescriptive warnings that make it longer than the minimum needed, even though most content earns its place for a complex history 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?

Given a nested query object, zero schema parameter descriptions, and no output schema, the description supplies enough context to call the tool correctly: it covers source/var distinctions, forecast spot requirements, time-window and point limits, row-quality filtering, provenance expectations, units, and the shape of returned metadata. Missing enumerations of source/var values are acceptable in an open-world environmental data 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?

With schema description coverage at 0%, the description must carry parameter meaning, and it largely does: it explains source and var, specifies that forecast source uses forecast:model and requires spot, mentions the 31-day window, and caps points at 1000. It does not fully elaborate every nested field such as from/to formatting or the spot pattern beyond the schema, so it stops short of full compensation.

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: 'Read stored observations or forecast history for source and var.' It then differentiates from the sibling tool by saying 'For chop history or trends use get_chop_history with a verified spot ID.' It also clarifies the forecast-source variant requiring spot and forecast:model, so an agent can distinguish this tool from adjacent history and observation tools.

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 explicit routing guidance: use get_chop_history for chop history or trends with a verified spot ID. It also states when the forecast-source mode applies: 'Forecast source uses forecast:model and requires spot.' Additional constraints such as the 31-day maximum window and 1000-point cap further define appropriate use.

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/openWorld/destructive=false, yet the description adds substantial behavioral context: data provenance, inclusion of dates/uncertainty/attribution/licenses, source/freshness metadata, and the critical caveat that source-check time differs from observation time. These are non-obvious traits that meaningfully change interpretation.

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 first sentences front-load purpose and sources well, but the text repeats the same caveats twice ('no sightings does not establish absence' / 'No records does not mean the animals are absent'; man-of-war-as-siphonophores stated twice). The trailing 'Units: ft, kt, s, F, mi; directions FROM' line is irrelevant boilerplate for an observation-listing tool lacking unit-bearing parameters.

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 describe returns ('data and source/freshness metadata') and provides rich interpretation caveats. Combined with the nested query schema, an agent has enough to call it correctly, though the bbox format gap slightly reduces completeness.

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%, so the description must carry the load. It explains limit's default (20) and maximum (100) and says bbox narrows the sample, but it never explains the bbox string format (e.g., minLon,minLat,maxLon,maxLat), which is the riskiest undocumented parameter for a nested query object.

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 (published Florida jellyfish, box jellyfish and man-of-war observations) and names the sources (OBIS and iNaturalist). It clearly differentiates itself from siblings like get_observations, get_shark_research, and get_red_tide by scoping to jellyfish/man-of-war and clarifying these are published records rather than live warnings.

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 explicit context and exclusions: it is 'not live tracking, beach warnings, abundance estimates or swimming-safety scores,' and 'Never apply NOAA's Chesapeake sea-nettle forecast to Florida.' It also tells the agent to use bbox to narrow the sample. It stops short of naming a specific alternative sibling tool, but the when-not guidance is strong.

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/openWorld/non-destructive, so safety is covered. The description adds genuinely useful behavior: unavailable states, preserved source sample dates, and return of source/freshness metadata. It is dragged down by a 'satellite clarity vs dive visibility' sentence that seems unrelated to a king tide tool and adds confusion rather than clarity.

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 core purpose and short overall, with the units line as a compact reference. The out-of-place 'satellite clarity' sentence spends words on a topic irrelevant to king tides, keeping it out of the top tier.

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, no-output-schema tool whose safety profile is carried by annotations, the units and metadata note give reasonable coverage. It still leaves gaps on how to obtain a valid spot and what the forecast actually returns, and one sentence appears copied from another domain.

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 0% and the single parameter is a nested 'query.spot' with a pattern and length constraints that are never explained. The description's 'verified spot' adds only a sliver of meaning and does not convey the expected ID format or the nested-object shape.

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 (king tide forecast) and a scoping condition ('for a verified spot'), which is clearer than a bare verb+noun. However, it never distinguishes itself from the sibling get_tides (or get_forecast), leaving the agent to guess which tide/forecast tool applies.

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 and no named alternative. 'For a verified spot' hints at a precondition but never says how to obtain a verified spot or when king tides differ from regular tides.

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 a safe, idempotent, non-destructive read, but the description adds genuine behavior beyond them: source/freshness metadata is returned, availability is disclosed, unit conventions (ft, kt, s, F, mi; directions FROM) are stated, and the empty-report caveat warns against a false-safe reading.

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, purpose front-loaded, with the units/return line last. Every sentence carries information, though the units list sits slightly awkwardly before the return statement.

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, and the description partly compensates by stating that data plus source/freshness metadata come back. However, the nested query parameter is entirely undocumented, leaving a real gap for a tool whose only input is that query object.

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 single query parameter with nested bbox and category fields has 0% schema description coverage, and the description says nothing about them. The unit list refers to returned values, not to how to populate bbox or category, so the parameter gap is unmitigated.

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 (Lake Okeechobee stage and releases) and its provenance (published agency dataset), so an agent can tell it apart from generic siblings like get_tides or get_canal_discharges. It stops short of explicitly contrasting itself with those nearest neighbors.

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 a caution ('Empty reports do not establish safe conditions') that tells the agent how to interpret a result, but no guidance on when to prefer this tool over alternatives such as get_canal_discharges or get_usgs_water. Selection remains inferred.

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 read-only, idempotent, open-world, non-destructive safety. The description adds genuinely useful behavior beyond that: stale feeds yield status=null with unavailableReason rather than a false 'clear', and results carry source/freshness metadata. It does not cover rate limits or pagination, but for a read tool the stale/never-false-clear disclosure is the key risk-relevant detail.

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 return-value content is well front-loaded, but the bulk of the text is a wall of unrelated interpretation rules about tides, model sea height, paddleboard drift, kitesurfing activity keys and launch access. Those sentences do not help an agent select or invoke get_lightning and materially dilute an otherwise focused definition.

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 describe returns, and it does: field-by-field for the point mode, a status-per-spot summary for the no-coordinate mode, plus freshness metadata and the null/unavailableReason contract. It is close to complete for invocation purposes; only the exact shape of the per-spot response is left thin.

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 single query object with optional lat/lon has 0% schema description coverage per the signals, so the description carries the load. It explains the semantic branch clearly ('With lat+lon: ... Without lat/lon: status per spot'), which tells the agent that omitting coordinates is a valid, different mode rather than an error.

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 (GOES-19 GLM lightning status) and enumerates exactly what is returned for each mode (level, nearest strike distance/time, strikes in 15 min, all-clear time, SPC outlook, last 30 min of flashes). It also distinguishes itself from the sibling list_spots for named-spot coordinates, so an agent can route 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?

The two operating modes are explicit (with lat+lon vs without, per-spot), and it names the alternative for named locations ('Prefer list_spots for named spot coordinates'). It also routes kitesurfing questions to get_conditions, though that guidance is about adjacent concerns rather than when to call this tool versus its lightning-relevant peers.

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. The description adds genuine value by disclosing that start/end times and source links are preserved and that freshness metadata is returned, but it omits freshness/pagination specifics and any mention of upstream data latency.

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 core purpose followed by unit conventions and return metadata. The units clause (ft, kt, s, F, mi; directions FROM) is arguably tangential for an alerts endpoint but is compact and harmless.

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 some work by sketching the return shape (start/end times, source links, freshness metadata). But for a tool whose only input is an opaque nested 'spot' identifier and which has openWorld behavior, the missing parameter explanation and source/freshness semantics leave the definition only partially complete.

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%, so the description carries the full burden, yet it says nothing about the single required parameter. 'spot' has only a pattern and length constraint in the schema; the description never clarifies whether it is a numeric ID, name, slug, or coordinate string, which is a real gap for a required nested param.

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 ('Active and upcoming alerts for a spot') with a clear read verb implied by the tool name, and it explicitly notes the temporal scope (active vs. upcoming). However, it does not distinguish itself from near-siblings like get_park_alerts, get_navigation_notices, or get_hazards, leaving the agent to guess which alert source applies.

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 guidance, no prerequisites, and no named alternatives despite a crowded alert/hazard sibling space. The agent is given the 'what' but must infer entirely on its own when this tool is the right choice versus get_park_alerts or get_navigation_notices.

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), but the description adds genuinely useful context: it requires a Gillby account with explicit account consent, and it returns source/freshness metadata. That is real behavioral disclosure beyond the structured fields.

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?

Purpose and auth are reasonably front-loaded, but the 'Units: ft, kt, s, F, mi; directions FROM' sentence is generic template boilerplate that has no bearing on notification settings and wastes space. The rest is efficient.

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

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

For a zero-parameter read tool with no output schema, the description covers purpose, auth/consent prerequisites, and the shape of the return (data plus source/freshness metadata). It could say more about what the preferences/channels actually contain, but it is largely complete.

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 baseline is 4. The description adds no parameter meaning (there is none to add), and the units line is irrelevant to this tool.

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 ('Read notification preferences and actual delivery availability'), which distinguishes it from the general get_my_settings and the mutating update_my_notification_settings. It stops short of naming those siblings, so it is clear but not maximally differentiating.

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 name and purpose; the description never says when to call this versus get_my_settings or update_my_notification_settings, nor any exclusions. Adequate for an obvious read tool but no explicit 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 declare read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context by disclosing account consent requirements, units, direction convention, and source/freshness metadata.

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 short, front-loaded, and structured: purpose first, then prerequisites, units, and return metadata. 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?

It covers purpose, auth/consent, units, and return metadata, which is helpful given there is no output schema. However, it leaves the only required nested parameter undocumented, which is a meaningful gap 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 description does not explain the nested path.id parameter, how the saved place is identified, or any constraints beyond the schema itself. It only implies a single saved place is retrieved.

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

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

The description clearly states a specific verb and resource: read one saved place. It implicitly distinguishes from list_my_places by saying 'one saved place,' but does not explicitly name siblings or scope boundaries.

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 implies usage for retrieving a single saved place and notes account/consent requirements, but gives no explicit when-to-use guidance, exclusions, or comparisons to list_my_places, get_spot, or update_my_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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is lower; the description still adds value by disclosing null semantics for missing vessel measurements, the auth/consent precondition, the unit conventions, and that freshness metadata accompanies the payload. It stops short of saying whether settings can be absent entirely or how the three setting groups are keyed.

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, front-loaded with the purpose and scoping behavior. The units line is compact and genuinely useful rather than filler, though it reads as a bolted-on convention block rather than part of a single narrative.

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 zero-parameter read with no output schema, the description covers what is returned ('data and source/freshness metadata'), the null case, units, and auth requirements. The shape of the returned settings object and the distinction from the narrower vessel/notification getters remain unspecified.

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 is 4 and there is no schema surface the description needs to compensate for. The unit and direction conventions it does state are output-side context rather than parameter meaning.

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: reading saved vessel, preference and notification settings. However, the sibling set contains get_my_vessel and get_my_notification_settings, and the description never clarifies how this aggregate read differs from those narrower tools, so the agent must guess which to 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?

Prerequisites are given ('Requires your Gillby account and explicit account consent'), which is real guidance about when the call will succeed. But there is no explicit when-to-use versus get_my_vessel, get_my_notification_settings or update_my_settings, so selection among the settings 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 already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond annotations: authentication and consent requirements, unit conventions, direction convention ('directions FROM'), and return metadata about source/freshness. It does not, however, disclose rate limits or error 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?

Three short sentences, front-loaded with purpose, then prerequisites, then units and return details. Every sentence contributes useful information without waste.

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 read-one tool with rich annotations and no output schema, the description gives enough to call it safely: auth requirement, units, and return metadata. The main gap is that it does not clarify the required trip id parameter. Overall, it is nearly complete for the tool's complexity.

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 single nested parameter 'path.id' is not explained in the description. 'Read one saved trip' implies an identifier but does not state that the parameter expects a trip id, its type, or its minimum value. The description leaves parameter meaning to inference.

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: 'Read one saved trip.' This distinguishes it from siblings like list_my_trips, save_my_trip, update_my_trip, and delete_my_trip. An agent can immediately tell it retrieves a single saved trip.

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 prerequisites ('Requires your Gillby account and explicit account consent'), which is useful context. However, it does not explicitly say when to use this tool versus list_my_trips or how to obtain the required trip id. Usage is implied but not fully guided.

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, and destructiveHint=false, so the safety profile is covered. The description still adds meaningful context beyond them: the OAuth requirement, an explicit scope boundary ("no writes and no other account access"), and the fact that freshness/source metadata accompanies the 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?

Three short sentences with no filler; the access requirement is front-loaded, followed by scope, then output conventions. Every clause carries information an agent would otherwise have to guess.

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 noting that data comes with source/freshness metadata and by fixing the units and direction convention. It stops short of indicating what a vessel record actually contains (name, draft, beam, clearance values), which is the remaining gap for a zero-param read.

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 is 4 and the schema (vacuously 100% covered) carries no burden. The units and FROM-direction conventions describe output rather than inputs, so they do not raise or lower this score.

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 (reads) and a specific, ownership-scoped resource ("your saved vessel and route clearance settings"), which distinguishes it from the public-object sibling get_boat. However, it never names get_boat or any other sibling explicitly, so the differentiation must be inferred from the possessive phrasing.

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 a real prerequisite ("Requires OAuth login to your Gillby account") and implies the use case via "your saved vessel," but it never states when to prefer this over get_boat or how it relates to get_my_settings/get_my_trip. Usage is implied rather than instructed.

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. The description adds genuinely new context: that results come with source/availability metadata and that an empty result set must not be read as confirmed safe conditions. That is a real behavioral caveat not present in annotations.

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

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

The core purpose and the empty-report caveat are front-loaded and well placed. However, the units/directions sentence and the metadata sentence are generic boilerplate that is only marginally relevant to a notices feed, diluting an otherwise tight description.

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, no annotation gaps filled beyond safety hints, and 0% schema description coverage on a nested query object, an agent gets no help on filtering (bbox format, category vocabulary) or on what a notice record looks like. The description is incomplete for a tool whose only entry point is an undocumented nested parameter.

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?

There is one parameter object (query) with nested bbox and category properties, and schema description coverage is 0%. The description says nothing about how to format bbox, what category values are accepted, or what happens when query is omitted. The 'Units: ft, kt, s, F, mi; directions FROM' sentence is about data values, not parameters, so it does not compensate.

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+resource: USCG local notices to mariners from a published agency dataset. It is distinguishable from sibling tools like get_marine_alerts or get_hazards by naming the issuing agency and dataset. It stops short of explicitly contrasting with those 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?

The caveat 'Empty reports do not establish safe conditions' implies this tool is not a safety guarantee, which is useful. But there is no explicit guidance on when to call this instead of get_marine_alerts, get_hazards, or check_route_conditions. Usage must be inferred from the name.

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 safety (readOnly, idempotent, non-destructive) and openWorld, so the bar is lower. The description adds genuine behavioral context beyond annotations: the unit system (ft, kt, s, F, mi), that directions are FROM, and that output includes source/freshness metadata. It omits any rate-limit or pagination behavior but is solid otherwise.

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 segments, front-loading the core purpose before the units block. Every sentence carries information; nothing is padded, though the units line is dense.

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 appropriately discloses the return shape ('data and source/freshness metadata') and the unit conventions. Combined with the annotation coverage this is nearly complete, with only the spot parameter's format left unexplained.

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 there is one required nested parameter (spot). The description only restates 'for a spot' without clarifying the identifier format, valid sources, or the meaning of the spot value, so it fails to compensate for the schema 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?

States a specific verb and resource: 'Actual buoy and station observations for a spot with timestamps'. It also implicitly contrasts itself with forecast tools ('may differ from blended forecast conditions'), helping distinguish it from siblings like get_forecast/get_conditions. It does not name a specific sibling, so it stays just short of 5.

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 'These may differ from blended forecast conditions' implies this tool should be used when actual measured data is wanted rather than a forecast, but no explicit when-to-use rule or named alternative is given. Usage must be inferred from the forecast contrast.

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, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: it identifies the data source (published agency dataset), notes source/freshness metadata is returned, and warns that empty reports do not establish safe conditions — a genuinely important interpretive caveat for an alerts 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?

Purpose is front-loaded in the first sentence and the caveat follows immediately. The units line ('ft, kt, s, F, mi; directions FROM') is generic and only loosely tied to this tool's output, but overall the text is compact with little waste.

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 partially covers returns ('data and source/freshness metadata') but leaves the shape vague, and both filter parameters remain undocumented. For a simple read-only tool this is adequate but has clear gaps an agent would have to probe at runtime.

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 single nested query object exposes bbox and category with no documentation anywhere. The description says nothing about either parameter's format, semantics, or filtering behavior, so it fails to compensate for the schema 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?

States a specific resource ('Coastal national park alerts and closures') and its provenance ('published agency dataset'), which naturally separates it from sibling alert tools like get_marine_alerts and get_navigation_notices. However, it never explicitly names or contrasts those siblings, so an agent must infer the boundary 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?

There is no when-to-use guidance, no prerequisites, and no alternatives named. The caution 'Empty reports do not establish safe conditions' is a data caveat, not usage guidance, and does not tell the agent when this tool is the right choice over the many other alert/hazard 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 readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description goes beyond them by disclosing the data source, that availability/source/freshness metadata accompanies the payload, and the important caveat about empty reports not implying safety — genuine added context.

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?

Purpose is front-loaded in the first sentence, followed by the caveat and return metadata in short, waste-free sentences. The units/directions line reads like template boilerplate that is hard to reconcile with a pollution-notice dataset, which slightly muddies an otherwise tight structure.

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 cover the return shape ('data and source/freshness metadata'), which is the right move. However, for a nested query object at 0% schema coverage and no required parameters, the filtering mechanics remain unexplained, leaving a real gap an agent would need to close by 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?

Schema description coverage is 0% and the description never mentions the query object or its bbox/category fields, so the only filtering knobs are undocumented in both places. The 'Units' line describes measurement formatting, not how to scope a request, so 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?

States a specific resource ('Pollution incident notices') and its origin ('from the published agency dataset'), so the agent can distinguish it from neighbours like get_algae_reports, get_fish_kills or get_derelict_vessels. It does not explicitly differentiate itself from those siblings, but the resource is unambiguous.

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 and no named alternative among the many sibling dataset tools. The caveat 'Empty reports do not establish safe conditions' is interpretive context, not routing guidance, so an agent gets no help deciding when to call this versus get_algae_reports or get_marine_alerts.

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, open-world). The description adds real behavioral context beyond that: explicit nulls when data is unavailable, inclusion of source status and freshness metadata, and unit/direction conventions. This is genuinely useful disclosure the annotations do not carry.

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?

Purpose is front-loaded, but several sentences (water temperature in F, atmospheric visibility in mi, current sign convention) are off-topic for an air-pressure tool and dilute the signal. The units block reads as generic boilerplate rather than tool-specific.

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 partly compensates by noting timestamp and source/freshness metadata in the return. However, for a nested 0%-covered input schema it leaves the spot/hours semantics underspecified, so it is adequate but not complete.

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% for a nested query object with spot and hours. The description obliquely implies an hours horizon ('over the next hours') and a spot requirement ('verified spot'), but gives no identifier format, no hours bounds, and does not explain the spot pattern constraint.

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 opening sentence states a clear verb+resource: air pressure for a spot over the coming hours. It is specific about the resource but never contrasts itself with closely related siblings like get_air_temperature, get_wind, or get_conditions, so an agent must infer the boundary.

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, no alternatives named, and no exclusions. The only oblique hint is 'for a verified spot', which implies a prerequisite but does not state what to do when the spot is unverified or which sibling to use instead.

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; the description adds genuine context beyond that — agency provenance, that the response carries source/freshness metadata, and the important caveat that an empty result is not evidence of safe conditions. It still omits coverage/pagination or freshness-staleness behavior, so it stops short of 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?

The tool-specific sentences are tight and front-loaded, but the units/directions boilerplate has no bearing on a parameterless geographic lookup and reads as copied filler. Appropriately short overall, with some waste.

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 states that data plus source/freshness metadata is returned, and it flags the empty-result caveat. However, the two available filters (bbox, category) are left undocumented in both schema and description, and no usage context is given, leaving real gaps for a nested-object 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?

The schema has a nested query object with bbox and category at 0% description coverage, and the description never mentions either filter. The 'Units: ft, kt, s, F, mi; directions FROM' line is a generic footer that maps to no parameter of this tool, so it does not compensate for the documentation 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 a specific resource ('Marine protected areas') and its provenance ('from the published agency dataset'), so an agent knows this is a lookup of protected-area boundaries. It does not, however, distinguish itself from adjacent lookups in the sibling list such as find_reefs, get_poi, or search_pois.

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?

'Empty reports do not establish safe conditions' is an interpretive caution, not usage guidance — it never says when to call this tool versus get_park_alerts or the find_* siblings, nor what inputs are expected. There is no explicit when-to-use or when-not-to-use statement.

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, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description does add genuinely useful behavior: explicit nulls when unavailable, timestamp and source/freshness metadata. But it also leaks irrelevant unit details (water temperature F, current sign) and never states the rain accumulation unit, which is a notable omission for a rain 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 first sentence is well front-loaded, but the remainder is a pasted block of unit conventions covering water temperature, visibility, and currents that do not apply to rain. Those sentences do not earn their place and dilute the signal for the actual 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 carries the return-value burden and does mention timestamp, source status, null handling, and freshness metadata, which is solid. It still omits the rain accumulation unit and the hours bounds, and the irrelevant unit list makes the picture less complete rather than more.

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% for a nested query object with spot and hours, so the description must compensate. 'Verified spot' is a useful constraint the schema doesn't express, but hours (default 24, max 168) is only gestured at via 'over the next hours', and the spot pattern/verification mechanism is never explained. Partial compensation at best.

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 opening sentence gives a specific verb and resource ('Rain probability and accumulation... over the next hours') and scopes it to a verified spot, which is clear enough to separate it from sibling weather tools. However, the body immediately drifts into water temperature, atmospheric visibility, and current sign conventions, which are properties of other tools, not rain. That off-topic content muddies an otherwise clean purpose statement.

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 a weak temporal hint ('over the next hours'), but no explicit when-to-use, when-not-to-use, or alternative routing against siblings like get_forecast, get_conditions, or get_thunder_forecast. An agent gets no guidance on when rain deserves its own call versus a general forecast call.

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, openWorld, non-destructive), yet the description adds real context beyond them: data may carry 'unavailable states', source sample dates must be preserved, satellite clarity is a relative index not true dive visibility, and it returns source/freshness metadata. These caveats meaningfully affect interpretation of 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?

Front-loads the purpose and keeps to a few sentences, but the telegraphic unit string ('Units: ft, kt, s, F, mi; directions FROM.') reads awkwardly and is not clearly tied to specific fields. It is compact but not maximally clear.

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 state that it returns data plus source/freshness metadata and lists units, which partially covers return semantics. However, it leaves the sole required parameter and the meaning of individual returned fields under-explained for a data-heavy 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 0% and there is one nested required parameter ('query.spot'). The description only says 'for a verified spot' without explaining the spot identifier format, how to obtain one, or the nested structure constraint, leaving the parameter effectively undocumented.

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 ('Red tide samples for a verified spot'), which is clearly scoped to a single data product. It doesn't explicitly distinguish itself from the many adjacent marine-biology siblings like get_algae_reports or get_fish_kills, so an agent must infer the difference.

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 'for a verified spot' implies a precondition, but there is no explicit when-to-use, when-not-to-use, or alternative routing against the closely related get_algae_reports/get_visibility tools. An agent has no guidance on tool selection.

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, openWorld, non-destructive), yet the description still adds real behavioral context: source sample dates and unavailable states must be preserved, and satellite clarity is explicitly a relative index rather than measured dive visibility. It also discloses that source/freshness metadata is returned, which is not visible in any structured field.

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, front-loaded with purpose, then caveats, then units and return shape. The units/directions line is terse but dense with useful convention information; little 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 and 0% parameter coverage, the description does the minimum-plus: it hints at return contents (data plus source/freshness metadata) and flags unit conventions. However it never describes the risk scale or categories, what an unavailable state looks like, or how an unverified spot is handled, leaving meaningful gaps for a domain-specific hazard 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 0% for the single nested 'spot' parameter, so the description carries the burden. 'Verified spot' adds a meaningful constraint not present in the schema (which only shows a regex and length limits), but it never explains the expected spot identifier format or how verification status is determined. Partial compensation only.

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 and verb-equivalent ('Rip current risk for a verified spot'), which is clearly distinct from siblings like get_waves, get_currents, or get_surf_forecast. It does not explicitly name a sibling to route against, but the resource is unambiguous.

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 guidance, no statement of when another tool (e.g. get_surf_forecast or get_hazards) is preferable, and no explanation of what makes a spot 'verified' or what to do if it is not. The agent must infer the usage context entirely.

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, open-world), so the description earns credit for what it adds: 'Preserve source sample dates and unavailable states' warns that data may be missing and that sample dates matter, and 'Satellite clarity is a relative index, not measured dive visibility' prevents a serious misinterpretation. Return metadata ('source/freshness') is also disclosed.

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 short and front-loaded, leading with the purpose before caveats and the compressed 'Units: ft, kt, s, F, mi; directions FROM' clause. Nothing is redundant, though the unit string is dense enough to be slightly cryptic.

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 appropriately states what comes back ('data and source/freshness metadata'), supplies unit and direction conventions, and flags unavailable states and the relative nature of satellite clarity. Given the one-parameter, nested-object input, the main remaining gap is the spot identifier format.

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% for the single nested 'spot' string, so the description must carry the burden and largely does not. 'Verified spot' hints that the value must correspond to a known spot, but the required format (pattern, 1-120 chars) and whether it accepts an id versus a name are left 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?

The description states a specific resource and scope: 'Local sargassum risk for a verified spot', which tells the agent exactly what is retrieved and that it is spot-scoped and local. It does not, however, differentiate itself from the very close sibling get_sargassum_outlook, leaving the agent to infer the local-vs-outlook distinction from names alone.

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 only usage signal is the phrase 'for a verified spot', which implies a precondition but does not explain what 'verified' means or how to satisfy it. With get_sargassum_outlook, get_algae_reports and get_red_tide as adjacent siblings, the description offers no when-to-use-this-vs-that guidance or 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 read-only, idempotent, open-world, and non-destructive behavior. The description adds a useful caveat about empty reports and mentions source/freshness metadata, but it does not explain freshness rules, data limitations, or return behavior in detail.

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 short and front-loads the resource and safety caveat. There is minor redundancy around 'availability' and the units line may be boilerplate, but overall it is efficiently sized.

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, and the description only briefly mentions return metadata without describing the return shape or freshness fields. Combined with zero schema coverage for bbox and category, the definition is incomplete 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 single nested query parameter with bbox and category fields is not mentioned or explained in the description. The description does not compensate for the undocumented parameters at all.

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 as sargassum research product availability from an agency dataset, but it does not use a specific action verb or clearly explain what an 'outlook' contains. It also does not distinguish this tool from sibling tools like get_sargassum or get_algae_reports.

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 only usage-relevant statement is the safety caveat that empty reports do not establish safe conditions. There is no guidance on when to choose this tool over get_sargassum, get_algae_reports, or other related 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 cover the read-only/idempotent/non-destructive profile, so the description rightly focuses on semantic caveats: 'No records does not mean sharks are absent', 'source checked time is not observation time', and 'returns data and source/freshness metadata'. These are genuinely useful behavioral disclosures an agent would otherwise miss, even if some of the jellyfish/man-of-war material reads as boilerplate.

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 text is bloated and repetitive: 'No records does not mean sharks are absent' appears twice in near-identical form, units and NOAA Chesapeake sea-nettle forecast notes are irrelevant to this tool, and the important scoping sentence is buried mid-paragraph. Front-loading is poor and several sentences do not earn their 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 no output schema, the description usefully states that it returns data plus source/freshness metadata, and it sets expectations about absence of records and observation-date fidelity. Combined with the parameter coverage, an agent has enough to call it correctly, though the disjointed organization makes it harder to extract.

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%, so the description must carry the load and largely does: bbox is described as the spatial narrowing mechanism and limit is documented with default 20 and maximum 100, matching the schema constraints. It doesn't explain the bbox string format (lat/lon ordering), which is the one real 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 first sentence specifies the resource (published Florida shark research occurrences) and the fields returned (observation dates, location uncertainty, source credits, licenses). It distinguishes itself from live tracking and beach warnings, and from the sibling get_jellyfish_observations by being acoustic detections/tag releases. The verb is implied rather than stated and the rambling dilutes the signal, but an agent can identify the tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage for parameters ('use bbox to narrow the published sample', limit default 20 / max 100) and a clear negative scope (not live tracking, not beach warnings). However it never names an alternative tool or states the condition under which an agent should reach for this versus get_jellyfish_observations or get_observations, leaving routing 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by naming the four status categories and the direction convention ("directions FROM"), but it says nothing about latency, coverage limits, or what happens for a spot with no sources.

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, front-loaded with the status taxonomy that matters most. The units/directions line is compact but a little cryptic standing alone; still, there is no filler.

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