Veabird: ski & beach trip planner

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 genuinely useful behavior beyond that: date-dependent output character (live+alerts for today, forecasts for days 0-15, climate outlooks beyond), which an agent could not derive from 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?

Two sentences, front-loaded with scope before the metric list and temporal behavior, with no filler. The metric enumeration is long but each item conveys distinct returned 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?

There is no output schema, so describing the returned payload (score with per-metric detail, sargassum, weather, waves, UV, crowds, hurricane risk, holidays) is exactly the missing information, and the temporal forecast/live distinction completes the picture 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 100% with only 2 params, so the schema fully documents 'date' format/range and 'resort' as id-or-name. The description reinforces the one-resort/one-date constraint but adds no syntax or format detail beyond the schema, matching the baseline.

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

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

States a specific resource and scope: full conditions for one beach resort on one date, with an explicit enumeration of the returned metrics. It clearly reads as a superset tool versus narrow siblings like sargassum_forecast or tides, but it never names an alternative to make the distinction explicit.

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

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

Provides temporal usage guidance ('For today, also live conditions and alerts. Days 0-15 are forecasts, later dates climate outlooks'), implying when a date is worth querying. However, it gives no when-to-use/when-not versus siblings such as rank_beaches or better_nearby_beaches, leaving alternative selection 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, idempotent, non-destructive and openWorld, so safety is covered. The description adds useful behavior beyond that: the 16-day date ceiling and the 'meaningfully higher score' selection criterion. It still omits return format, pagination, and how radius defaults behave.

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

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

A single dense sentence with the core scope front-loaded ('For a beach resort and date... nearby resorts with a meaningfully higher beach score'). It wastes nothing, though the colon-clause tail reads as slightly clipped.

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, so the description should carry return-value expectations; it gestures at the result (nearby higher-scoring resorts) but leaves 'meaningfully higher' undefined and says nothing about how many results or how radius affects them. Adequate but with clear gaps for a 3-param 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 only 33% (just the date format), so the description must compensate. It does add the 16-day constraint on date, but resort and radiusMiles receive no semantics in the schema or the description, and radiusMiles bounds (25-1000) go entirely unexplained.

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

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

The description names a concrete output (nearby resorts with a meaningfully higher beach score) for a given resort and date, so an agent can tell it apart from search_beach_resorts or rank_beaches. It does not explicitly name a sibling it is not, and 'swap suggestions' is slightly colloquial, but the resource and purpose are clear.

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 triggering scenario ('when sargassum or weather is bad') and the 16-day horizon, which is real usage context. However, it names no alternative tools (e.g. sargassum_forecast, beach_conditions) and gives no when-not guidance, so the routing 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, covering the safety profile. The description adds useful non-obvious behavior by stating that searches come pre-filled from the traveler's home airport and include the drive from each gateway airport to the resort. It does not, however, disclose what the response contains (fares, airlines, drive times).

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

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

A single front-loaded sentence that conveys the tool's scope and its distinguishing feature (gateway airports plus drive time) without filler. Slightly clause-heavy but nothing is wasted.

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

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

For a read-only, idempotent search tool with full schema coverage and annotations carrying the safety profile, the description supplies the essential purpose and the notable pre-filled/drive-time behavior. Only return-value expectations are left unspecified, which is acceptable since no output schema exists but is not strictly required 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 100%, so all six parameters (including adults, depart, return, childrenAges) are already documented in the schema. The description only restates the from/to flexibility ('or any airport code') and adds no new syntax or format detail, so the baseline of 3 is appropriate.

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

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

States a specific verb (searches flights) and resource (pre-filled flight searches to gateway airports for a resort), and clarifies the destination can be a resort or any airport code. It is clearly distinguishable from search_beach_resorts or find_lodging, though it never names a sibling explicitly.

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

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

Usage is implied by the content (flight search to a resort) and the input schema makes the trip-planning context obvious, but there is no explicit when-to-use guidance, no mention of prerequisites, and no routing against alternatives like find_lodging or plan_trip.

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 and open-world behavior, so the safety profile is covered. The description still adds real value beyond that: it discloses data freshness (live nightly prices), what may be missing (ratings and photos 'where available'), and the sourcing model (local property managers booked direct, no booking-site fee, plus hotel and vacation-rental searches).

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?

Everything is packed into one front-loaded sentence: the primary use case and location formats come first, with enrichment details trailing. It is dense and slightly run-on, but no sentence is wasted.

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

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

With 9 parameters and no output schema, the description usefully compensates by describing what comes back (nightly prices, ratings, photos) and the inventory mix. Budget and party filtering are acknowledged, though date/occupancy constraints and result limits are left entirely to the schema.

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

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

Schema description coverage is 89%, so the schema already documents near, rooms, adults, checkin/checkout, radiusMiles, childrenAges and maxPricePerNight. The description reinforces that budget filtering exists ('filtered by budget') but adds no syntax, defaults, or ranges beyond the schema, so 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 opens with a specific resource and scope: 'Places to stay near a ski or beach resort (or any lat,lon) for given dates and party,' which cleanly distinguishes a lodging search from siblings like search_ski_resorts and search_beach_resorts. It stops short of naming an alternative sibling explicitly, so it falls just below the top tier.

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 context is implied by 'near a ski or beach resort... for given dates and party,' letting an agent infer when the tool applies. However, it never states when to prefer this over search_beach_resorts or search_ski_resorts, or any prerequisites/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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description still adds value by disclosing the return payload: ranked picks with reasons plus lodging, flight and rental links. It does not mention rate limits or how ties/scores are computed, but for a read-only recommender this is solid.

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

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

Two sentences, front-loaded with the ranking function and followed by the return payload and a usage trigger. Slight redundancy in the parenthetical enum lists that the schema already carries, but no filler sentences.

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

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

With no output schema, the description correctly compensates by naming what is returned (reasons plus lodging/flight/rental links). It also covers the personalization factors behind the 11 optional parameters. The missing piece is any guidance on defaults or how it differs from search_ski_resorts for an agent choosing between 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 description coverage is 100%, so every one of the 11 parameters is already documented with examples, defaults, ranges and enums. The description restates the conceptual inputs (ability, dates, home airport/city, pass) without adding syntax or edge-case meaning beyond the schema — the baseline 3 for schema-dominant tools.

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 (ranks) and resource (ski resorts) and enumerates the ranking dimensions — ability fit, snow/crowds, travel mode, pass — so the agent knows exactly what this tool produces. It implicitly contrasts with search_ski_resorts (ranking vs. plain search) but never names the sibling, so differentiation is left 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?

The closing phrase "Use for 'where should I ski' questions" gives a concrete trigger, which is better than nothing. However, there is no when-not guidance and no routing to search_ski_resorts or ski_conditions for the sibling cases, so the agent must infer the boundary itself.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint). The description adds genuinely useful behavioral context beyond them: the scoring is cross-validated ('scored without using the station being scored'), drawn from a fixed station panel across terrain types, and benchmarked against a single-model baseline. It does not mention cost, rate limits, or how fresh the record is.

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

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

A single sentence that front-loads the core purpose and packs the metric definitions into its subordinate clauses. It is dense and slightly run-on, but every clause carries information (metrics, station panel, validation method, baseline) and nothing is filler.

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

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

With no parameters and no output schema, the description must carry the return-value burden, and it does specify the metrics reported (high/low error by lead day, Brier score, station panel, baseline comparison). It omits the time window the record spans and any framing of output shape, which are the remaining 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument call.

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 capability: Veabird's historical point-forecast accuracy, broken down into average daily high/low error by lead day and a Brier score for rain/snow probability. This clearly separates it from point_forecast (the forecast itself) and from sargassum_model_skill (a different domain's skill metric). It never explicitly names a sibling to route against, 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?

Implied usage is discernible — consult this when you want evidence of how reliable Veabird's forecasts are versus a typical weather-app model — but there is no explicit when/when-not statement, no prerequisites, and no named alternative for obtaining similar validation. Adequate but with a clear 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 declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds meaningful context beyond them: the upstream source (NOAA NHC), the geographic scope (Atlantic only), and what the response contains (position, intensity, track, at-risk resorts), which helps an agent judge freshness and coverage.

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

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

A single dense sentence that front-loads the core resource and appends the resort-threat twist; no filler or repetition. It is slightly overloaded with fields in one clause but earns every word.

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

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

For a one-parameter, read-only query tool with no output schema and full annotation coverage, the description is close to sufficient: it states the data source, scope, and returned fields. Only per-parameter semantics and refresh cadence are left implicit.

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 a single optional 'resort' parameter and the schema already documents it at 100% coverage, so the baseline is 3. The description's mention of 'threatened resorts' aligns with the parameter but adds no format or matching semantics (e.g., exact resort name vs. free text).

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 (active Atlantic tropical storms and hurricanes), a data source (NOAA NHC), and the payload (position, intensity, track, plus threatened Veabird resorts). That is well beyond a restated title, though it never explicitly distinguishes itself from domain-adjacent siblings like travel_advisory or beach_conditions.

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 this is the tool for hurricane-threat queries, but there is no explicit when-to-use, no exclusions, and no pointer to an alternative such as travel_advisory for non-hurricane risk.

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 and open-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the underlying models (ECMWF SEAS5, NOAA CPC in the US), the 35-year local climate baseline with warming trend, and the probabilistic nature of the output. No rate limits or caching behavior are mentioned.

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 packed with concrete output detail, so no sentence is wasted. However it is a single dense run-on sentence with stacked parentheticals, which makes the monthly/date/weekly distinction 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?

There is no output schema, so the description carries the full burden of explaining return values, and it does so thoroughly: monthly probability distributions, expected vs normal highs and lows, wet/snow days, date-specific rain/snow/freeze/hot-day chances, and the 6-week weekly odds. An agent knows what it will get back.

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

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

Schema description coverage is 100%, with every parameter documented including units, date patterns, month counts, elevation and ski-resort spot. The description adds little parameter-level guidance beyond confirming the seasonal/per-date framing, so the baseline 3 applies.

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

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

States a specific resource (long-range seasonal weather outlook, months ahead) and enumerates exactly what it returns: per-month probability of below/near/above-normal temperature and precipitation, expected highs/lows, wet/snow days, plus a date-specific and 6-week weekly view. The 'months ahead' scope cleanly separates it from short-horizon siblings like point_forecast.

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

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

The description implies its use case (planning for a future date or season) and the schema mentions a wedding/race/trip, but it never states when to prefer this over point_forecast or plan_trip, nor any exclusions or prerequisites. Usage is inferable 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 read-only, idempotent, open-world, and non-destructive behavior, so the safety profile is covered. The description adds useful behavioral context by enumerating what the tool returns: conditions, live nightly prices with photos, rental and hotel searches, flights, and extras like lift tickets and insurance.

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

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

The description is a single, well-structured sentence with a colon-separated list that is front-loaded with the core purpose: 'Everything to book one trip.' It is dense but every listed component earns its place by clarifying the tool's breadth.

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

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

For an eight-parameter aggregator with no output schema, the description sufficiently communicates the breadth of returned information and the annotations cover safety. It could go further by explicitly relating itself to sibling tools, but the overall context is strong.

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

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

Schema description coverage is 100%, so the input schema already documents all eight parameters thoroughly. The description reinforces some semantics, such as flights from the traveler's airport and lodging budget, but adds no new syntax or constraints beyond what the schema provides.

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: it plans a comprehensive ski or beach resort trip, enumerating conditions, lodging, flights, and extras. It functions as an umbrella aggregator, so an agent can infer its scope even without explicit sibling naming, though it does not call out alternatives by name.

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 clear context for when to use it: 'Everything to book one trip' signals a comprehensive trip-planning scenario. It does not explicitly list when not to use it or name sibling tools, but the context is strong enough for an agent to distinguish it from single-purpose searches.

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/destructiveHint=false, so the safety profile is covered; the description goes further by disclosing the data pipeline (multi-model blending, station bias correction, 82 ensemble members) and the 16-day ceiling. It does not mention latency, rate limits, or cost, which is the remaining gap.

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 clause, which is good, but the remainder is a single run-on sentence enumerating eight model names and ensemble mechanics, plus a promotional 'more accurate than a single-model app.' Some of that builds trust; a fair amount is marketing weight an agent does not need to select or call the 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 usefully states what comes back per day (rain, snow, temperature-range probabilities, plus a typical-app comparison), and the 5-param schema is fully documented. Missing only secondary operational details such as response size, latency, or failure modes for unknown locations.

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

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

Schema description coverage is 100%, so the schema already documents days, spot, units, location and elevationFt. The description reinforces the 'location + elevation' precision concept but adds no syntax or format guidance beyond what the schema states, which is the expected baseline when the schema does the heavy lifting.

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

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

The opening clause gives a specific verb+resource ('Day-by-day weather... for an exact location and elevation') with an explicit horizon of up to 16 days, so an agent immediately knows what it gets. It never names or contrasts with siblings like long_range_outlook, ski_conditions, or forecast_skill, so differentiation is left implicit.

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

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

The 16-day cap and 'exact spot' framing imply when this tool applies, and 'more accurate than a single-model app' hints at a precision-oriented use case, but there is no explicit when-to-use, when-not-to-use, or named alternative for longer horizons or resort-level conditions. Usage must be inferred from the siblings' names.

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, openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: it enumerates the event categories considered, describes the iCal cross-referencing of booked vs. open nights, and explains the output shape (under-priced night flags plus a suggested range).

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

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

Front-loaded with purpose and audience, then behavior, then usage triggers. A single dense paragraph rather than bullets, but every clause carries information and nothing is filler.

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

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

With no output schema, the description carries the burden of describing returns and does so (booked/open night marking, low-price flags, suggested range). Seven parameters at full schema coverage need no further prose; a note on failure modes or non-US coverage would make it 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 100% with rich per-parameter docs (defaults, ranges, iCal export steps), so the schema does the heavy lifting. The description only echoes the calendar source and nightly-rate ideas, adding no syntax or format detail beyond what is already structured.

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 chain (nightly demand around a property vs. a typical night, booking status from iCal, under-pricing flags and a suggested range), with the audience named up front. No sibling tool in the list does anything similar, so differentiation is automatic.

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?

Ends with an explicit trigger list: 'Use when a host asks whether their price is too low, what's happening in town, or when to raise rates.' Clear context for invocation, but no when-not condition or named alternative (e.g., when a host only wants events, not pricing).

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/open-world, so the safety profile is covered. The description adds real behavioral context beyond them: `from` additionally returns airports and a flight search, and dates beyond 16 days require a narrow query or `near`. Return shape (ranked list with scores) is only loosely implied.

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

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

Two sentences, front-loaded with the core ranking semantics before the scope modifiers and the usage cue. No filler or restated boilerplate.

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 sketches what comes back (ranked resorts with 0-100 scores, plus airports and a flight search when `from` is set), which is adequate for a read-only ranking tool. The default behavior when no filters are supplied could be stated more explicitly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter semantics the schema does not: the interaction of `from` with airport/flight output, and the query-vs-near vs date-window tradeoff. It still doesn't clarify how `query` and `near`/`radiusMiles` combine.

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 ('rank beach resorts by 0-100 beach score') plus the filtering dimensions (region/island/country/radius). It implicitly distinguishes ranking from plain discovery, but never names the obvious sibling search_beach_resorts, so sibling differentiation is left 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?

Explicitly gives the triggering question type ('where should I go to the beach'), which is clear usage context. It stops short of stating when NOT to use it or naming alternatives such as search_beach_resorts or better_nearby_beaches.

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 the safe read-only, idempotent, non-destructive profile, so the description's burden is lighter. It usefully adds what the caller actually receives — a 16-day daily detail plus a weekly monthly outlook, barrier/cleanup program information, and model source and held-out skill — which is meaningful behavioral context in the absence of an output schema.

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

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

One dense sentence that is front-loaded with the core purpose (forecast horizon) before enumerating supplementary returns. It is efficient, though the trailing item list ('barrier and cleanup programs, the model's source and held-out skill') is somewhat tacked 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?

For a two-parameter read-only tool with no output schema, the description covers the return content well enough that an agent knows what it will get, and annotations cover the safety profile. The main gap is the missing tie-breaker against the closely related sargassum_model_skill sibling.

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

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

Schema coverage is 100%, so both 'resort' and 'weeks' are already documented in the schema, making the baseline 3. The description's '16 days in detail plus a weekly outlook' implicitly clarifies the daily-vs-weekly granularity that the 'weeks' parameter controls, adding marginal value but no syntax or format detail beyond the schema.

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

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

The description names a specific resource (sargassum/seaweed outlook) and scope (next 16 days in detail plus a weekly outlook for coming months) plus supplementary content like barrier/cleanup programs and model skill. It is clear what the tool returns, but it does not distinguish itself from the sibling sargassum_model_skill, which the 'model's source and held-out skill' clause appears to overlap with.

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 through the description of output content; there is no explicit when-to-use statement, no exclusions, and no routing guidance versus alternatives such as beach_conditions, sargassum_model_skill, or plan_trip. The mention of model source/skill even creates ambiguity about which sibling to pick.

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 that the evaluation is on held-out years and compared against baselines, which is useful content, but it says nothing about output shape or interpretation (e.g., what a good AUC looks like) beyond the metric names.

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

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

A single sentence that front-loads the subject (the model) and lists the metrics compactly. No filler sentences, no redundancy with the title beyond what is necessary.

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 no-parameter, read-only informational tool with no output schema, the description is sufficient: it names the metrics and the comparison baseline an agent will receive. It stops short of explaining how the metrics should be interpreted or the time span of held-out years.

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 are no argument semantics to document; the baseline for a parameterless tool is 4. The description correctly implies no inputs are needed to obtain the report.

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 (Veabird's sargassum model performance) and enumerates the reported measures (AUC, Brier score, calibration) against baselines, so an agent understands it retrieves an evaluation report rather than a forecast. It does not explicitly distinguish itself from the sibling sargassum_forecast, which is the main ambiguity an agent could face.

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 describing held-out-year metrics, it signals this is the tool for inspecting model quality rather than getting a prediction. There is no explicit when-to-use, when-not-to-use, or pointer to sargassum_forecast as the alternative for actual forecasts.

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). The description adds useful context beyond that: the dataset size and geographic coverage, and the shape of results (ids, today's headline conditions, photos, page links). It omits pagination/limit behavior, which keeps it 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?

Two tight sentences with no waste; the corpus scope is front-loaded and the return summary follows. Every clause 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?

With no output schema, the description usefully summarizes return contents, and no parameters are required, so a bare query is valid. The only gap is the unexplained limit parameter and any result-cap behavior, which an agent would need when paginating.

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

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

Schema coverage is 50%: query has an example description while limit is undocumented. The description expands on query by listing the searchable facets (name, town, island, region, country), which adds meaning, but says nothing about limit or expected result counts, so it only marginally exceeds the schema baseline.

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

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

States a specific verb (Search) plus resource (beach resorts), scopes the corpus (1,400+ resorts across named regions), and enumerates the searchable facets (name, town, island, region, country). It is immediately distinguishable from the parallel sibling search_ski_resorts.

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 name and facets imply that this tool is for locating resorts, but the description never states when to use it versus siblings like beach_conditions, rank_beaches, better_nearby_beaches, or find_lodging, nor does it name any exclusion or alternative. Usage 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 read-only/idempotent/openWorld, so the safety profile is covered. The description adds real behavioral value by naming the return payload (ids, terrain mix, passes, gateway airports, forecast links), which no annotation or output schema conveys.

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 clauses: capability first, return contents second. No filler, no restatement of the title, and the scope count is front-loaded.

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, describing the return fields is the right move, and it does so. The main residual gap is the limit parameter's behavior and result pagination, which an agent may need for large result sets.

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

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

Schema coverage is only 33% (query only), but the description compensates by naming the searchable facets for query and the pass filter. Only 'limit' is left unexplained, so most of the coverage gap is closed by 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+resource with scope ('Veabird's 317 ski resorts') and the searchable facets (name, country, state, range). It does not distinguish itself from the sibling find_ski_resorts, leaving the agent to guess which of the two ski-resort lookups to pick.

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 'optionally only those on a pass' implies a filtering use case, but there is no explicit when-to-use guidance and no routing to or away from find_ski_resorts or ski_conditions. Usage is inferable from the facets listed rather than 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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description goes beyond them by detailing the payload: a 0-100 score with named inputs (fresh snow, base depth, weather, crowds), a 7-day forecast window, crowd outlook, terrain mix, passes and gateway airport. It does not mention freshness/update cadence or how the score is sourced, which keeps it from 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?

One dense sentence that front-loads the headline output (today's score) before the supporting data. Every clause corresponds to a distinct returned data group; nothing is padding.

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

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

With no output schema, the description carries the return-value burden and does so comprehensively — score, forecast horizon, crowd, terrain, passes, airport. Combined with annotations covering the safety profile and a fully documented single parameter, an agent has everything needed to invoke and interpret this 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?

There is a single required parameter and schema coverage is 100%, so the schema already documents 'resort' with an example. The description only reinforces the cardinality ('for one ski resort') and adds no format, aliasing, or disambiguation guidance beyond the schema.

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

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

The description names the resource (one ski resort) and enumerates exactly what the tool produces: today's 0-100 score with its components, 7-day summit snowfall/temperature, crowds, terrain, passes and gateway airport. It is clearly a conditions-report tool rather than a search tool, though it never explicitly contrasts itself with siblings like find_ski_resorts or search_ski_resorts.

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

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

Usage is implied — you call it for a specific resort when you want current and near-term snow conditions — but there is no explicit when-to-use statement, no prerequisites, and no pointer to find_ski_resorts/search_ski_resorts for resort discovery. The agent must infer the routing itself.

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 non-destructive, so safety is covered. The description adds genuinely useful non-annotation context: the Open-Meteo sea level model as source and that heights are relative to mean sea level, plus a forecast horizon. It does not cover rate limits, timezone of the times, or refresh cadence.

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

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

A single front-loaded sentence with no filler; the model source and datum are packed into a parenthetical. Efficient, though the parenthetical slightly buries operational info.

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

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

For a simple two-parameter read-only forecast with no output schema, the description covers what the data is and its reference datum. The gap is the input side: neither parameter's expected format or limits are conveyed, leaving the agent to guess at the resort identifier.

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, and it largely does not. 'resort' is never explained (what form of name/ID?), and the 'days' parameter is only alluded to as 'the next days' with no mention of the 1-7 maximum enforced by the schema.

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

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

States a specific verb+resource: high/low tide times and heights at a beach resort, with a forecast horizon. It is clearly distinguishable from siblings like beach_conditions or sargassum_forecast, though it does not name any sibling explicitly.

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

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

No when-to-use guidance, no exclusions, no pointer to alternatives. Usage is only implied by the tide/forecast framing; an agent gets no help deciding between this and beach_conditions for coastal info.

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 behavioral value by identifying the data source (US State Dept), the return content (level 1-4, summary, plus proprietary local safety notes) and the fact that it resolves a resort to its country — content not derivable from the annotations, and there is no output schema to carry it.

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

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

A single front-loaded sentence; the data source and payload lead, with scope at the end. It is slightly run-on ('a country or a beach resort's country') but wastes no words.

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

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

With no output schema the description usefully enumerates what is returned, and annotations cover the safety profile, so the core is sufficiently covered. However, with 0 required parameters it never says what happens if neither country nor resort is supplied, leaving a genuine ambiguity an agent could hit.

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

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

Schema coverage is 50% — country is documented with ISO2/name examples but resort has no schema description at all. The description compensates by explaining that a beach resort input maps to its country, clarifying the relationship between the two parameters, though it does not specify the resort name format or precedence if both are supplied.

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 (US State Department advisory level 1-4 plus summary and Veabird local notes) and its scope (a country or a resort's country). It is clearly distinct from weather/condition siblings like hurricane_threats and beach_conditions, though it never names or contrasts any sibling explicitly.

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

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

Usage is implied (look up safety for a destination you are considering) but there is no explicit when-to-use, when-not, or named alternative. The mention of 'a country or a beach resort's country' hints at two access patterns without stating which to prefer or what to do when both are relevant.

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