Ocean conditions by location: water visibility, swell, wind, tide, plus dive and snorkel spot picks.
Scored across 6 tools
Each tool occupies a distinct decision axis: rank days (best_day), rank months (best_months), rank spots (recommend_spot), fetch facts for one spot (get_conditions), fetch climatology for a place (get_seasonality), or enumerate coverage (list_coverage). The closest pair is best_months vs get_seasonality, since both answer 'what is month X like', but one ranks and the other reports facts, and the descriptions make the distinction explicit. Minor residual risk that an agent picks best_day when it wanted a spot ranking, but the 'versus runner-up' / 'ranked top picks' framing differentiates them.
Five of six names are a clean verb_noun pattern (get_conditions, get_seasonality, list_coverage, recommend_spot, and arguably best_day/best_months as 'best_' + noun). The 'best_*' prefix is used as a consistent superlative family rather than a verb, which is a small but coherent deviation. No casing or stylistic chaos.
Six tools for a decision-support domain is well inside the sweet spot, and each maps to a non-redundant question type: facts, seasonality, day choice, month choice, spot choice, coverage. Nothing appears bolted on, and there is no pressure to merge distinct operations.
The surface covers the full planning lifecycle — coverage discovery, climatology, near-term facts, and ranked decisions across days, months, and spots — and gracefully reports uncovered/not-modeled states. Gaps are minor: there is no plain 'list spots in area' or 'get spot detail/metadata' call independent of ranking or conditions, so browsing a region without an activity in mind requires an indirect route.
Which day in a window (max 7 days) is best for an activity at a destination — a spot, a region, or lat+lon with a radius — and why, versus the runner-up. Returns every day's best score, confidence, caveats and a KaiCast spot card for the winner. Free during early access.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Window end, inclusive, at most 7 days. Default: from + 6. | |
| lat | No | Latitude, decimal degrees. Use with lon. | |
| lon | No | Longitude, decimal degrees. Use with lat. | |
| from | No | Window start, spot-local. Default: today. | |
| spot | No | Spot id, e.g. "hanauma-bay". | |
| region | No | Region id, e.g. "us-hi-oahu". | |
| activity | Yes | What the user wants to do. | |
| radius_km | No | Search radius around lat/lon in km (default 40, max 100). |
| Name | Required | Description |
|---|---|---|
| best | No | |
| days | No | |
| schema | Yes | |
| source | Yes | |
| status | Yes | |
| message | No | |
| coverage | Yes | |
| disclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — which it does by disclosing the return payload (every day's score, confidence, caveats, plus a KaiCast spot card for the winner) and the commercial status ('Free during early access'). It does not mention rate limits, latency, or behavior when a destination has no coverage, which is where a sibling like list_coverage would matter.
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 and a short pricing note, with the core capability front-loaded and the return contents immediately after. No filler, and the em-dash parenthetical efficiently enumerates the three location modes without a bulleted restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema and rich annotations, the description only needs to add the comparative framing and return shape, which it does. The remaining gap is that it never says how the three location modes interact (mutually exclusive? precedence?) or what happens on zero-coverage destinations, which matters for an eight-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns above that by clarifying that the location can be supplied as a spot, a region, or lat+lon with a radius, which is the one thing the schema leaves ambiguous (it never states these are alternative modes). The max-7-day window and default are reinforced, though the activity enum values 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 and resource: it identifies the best day within a bounded window for a named activity at a destination, and explicitly frames the result as a comparison against the runner-up. The day-level, max-7-day window implicitly separates it from best_months and get_conditions, but no sibling is named outright, so the differentiation is inferential rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the scope ('which day in a window is best for an activity') and by the location modes listed, but there is no explicit when-to-use/when-not guidance and no routing to best_months for longer horizons or to get_conditions for raw forecasts. The agent must infer the selection rule from the window bound alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks the calendar months for one thing at one place: an activity (dive, snorkel, freedive, whale_swim), a species (e.g. manta, whale shark), or calm seas / warm water / clear water. Says whether the ranking comes from multi-year data or curated research seasons, with confidence and caveats. A decision call: metered, free during early access.
| Name | Required | Description | Default |
|---|---|---|---|
| for | Yes | What to plan for: an activity (dive, snorkel, freedive, whale_swim), a species word (e.g. "manta", "whale shark"), or calm / warm / clear. | |
| lat | No | Latitude; resolves to the nearest covered area within 50 km. Use with lon. | |
| lon | No | Longitude; use with lat. | |
| area | No | Trip-planning area id, e.g. "us-hi-oahu". | |
| spot | No | Spot id; resolves to the area containing it. | |
| limit | No | How many months (default 3). |
| Name | Required | Description |
|---|---|---|
| for | Yes | |
| area | Yes | |
| basis | Yes | |
| months | Yes | |
| schema | Yes | |
| source | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds real context beyond them — provenance (multi-year data vs curated research seasons), confidence and caveats in the result, and a metering note ("metered, free during early access"). That cost/paywall disclosure is exactly what annotations cannot 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?
Three front-loaded sentences: what it ranks, what the output provenance is, then the operational note. No filler, and the most decision-relevant framing ("one thing at one place") comes first.
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?
Output schema exists, so return values need not be described, and the description still flags confidence/caveats and data source. The one omission is how location is resolved when only `for` is supplied, since area/spot/lat-lon are all optional — an agent gets no hint about precedence among those four location inputs.
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 every parameter including `for` examples, lat/lon 50 km resolution, area/spot ids, and the limit default is already documented. The description only reinforces the constraint that both the subject and the place are singular per call; it adds no new syntax or resolution detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("ranks the calendar months") plus the exact scope — one thing at one place — and enumerates the three kinds of inputs accepted. It separates itself from best_day by making the month granularity explicit, but never names a sibling for direct routing.
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?
"A decision call" implies this is the tool for planning-oriented questions, but there is no explicit when-to-use versus best_day, get_conditions, or get_seasonality. The agent must infer the boundary from the word "months" alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Facts for ONE covered spot over up to 7 days: 3-hour forecast periods with condition score (0-100) and rating, water visibility (ft), swell height/period/direction, wind, tide state and height, water temperature, plus tide events and data quality. Pass a spot id, or lat+lon to use the nearest covered spot within 30 km. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last day, inclusive. At most 7 days after from. Default: from + 6. | |
| lat | No | Latitude; snaps to the nearest covered spot within 30 km. | |
| lon | No | Longitude; use with lat. | |
| from | No | First day, spot-local YYYY-MM-DD. Default: today. | |
| spot | No | Spot id, e.g. "electric-beach". Pass this OR lat+lon. |
| Name | Required | Description |
|---|---|---|
| spot | Yes | |
| schema | Yes | |
| source | Yes | |
| periods | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld=false), and the description adds real context beyond them: the 7-day cap, the 30 km snapping radius, the inclusion of a data-quality field, and that access is free. It does not mention pagination or any failure mode when no covered spot is within 30 km.
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 resource and scope, then the input rule and cost in a short second sentence. The long comma-separated enumeration of return fields is somewhat dense and partly duplicates the output schema, but it is not padded or repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, date window, spot-vs-coordinate resolution, the 30 km fallback, and cost. With an output schema present, the return-value detail need not be in the description, and nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented, including the spot-OR-lat/lon exclusivity. The description restates the spot-vs-lat/lon choice and the nearest-spot rule, adding little syntax or format detail beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (ocean conditions) with explicit scope: facts for ONE covered spot over up to 7 days, enumerated as 3-hour forecast periods. The 'ONE spot' scope cleanly separates it from siblings like best_day and recommend_spot without needing to name 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?
Gives clear input-selection guidance ('Pass a spot id, or lat+lon to use the nearest covered spot within 30 km') and notes the tool is free, but never says when to prefer this over best_day or recommend_spot. Usage is implied by the fact-listing scope rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a place is usually like in a given month, for trip planning months ahead: per month, sea-surface temperature (p10/p50/p90 °C), wave height (p50/p90 m), wind (p50/p90 m/s), share of rough days, model water visibility (p25/p50/p75 m, low confidence), tropical-cyclone frequency, wildlife seasons, access rules and best activities. Every field carries its sources; curated seasons are drafts pending local review. Pass an area id, a spot id, or lat+lon, and optionally a month range. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude; resolves to the nearest covered area within 50 km. Use with lon. | |
| lon | No | Longitude; use with lat. | |
| area | No | Trip-planning area id, e.g. "us-hi-oahu". | |
| spot | No | Spot id; resolves to the area containing it. | |
| month_to | No | Last month, 1-12, inclusive; wraps the year (11 to 2 = Nov-Feb). | |
| month_from | No | First month, 1-12. Default: all 12 months. |
| Name | Required | Description |
|---|---|---|
| area | Yes | |
| months | Yes | |
| notice | Yes | |
| schema | Yes | |
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds real value beyond them: confidence caveats ('model water visibility, low confidence'), 'curated seasons are drafts pending local review', source provenance per field, and that the call is free. Return-shape detail is thinner but an output schema exists.
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 the input contract, then the field inventory. The long return-field list is partly redundant given an output schema exists, but it is dense and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations, a 100%-covered schema, and an output schema, the description covers what remains: the trip-planning horizon, confidence caveats, provenance, and cost. Only cross-tool routing guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters are already documented. The description only restates the input forms ('area id, a spot id, or lat+lon') without clarifying precedence when several are supplied, so it stays at 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?
Specific verb+resource: what a place is usually like in a given month, with the full field inventory named. The 'usually / months ahead' framing implicitly separates it from the current-conditions sibling, but no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'For trip planning months ahead' establishes the use context, and 'Pass an area id, a spot id, or lat+lon, and optionally a month range' tells the agent how to invoke it. It does not state when to prefer best_months, best_day, or get_conditions instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which regions and spots KaiCast covers, and whether each region supports ranked decisions (spot picks and best-day answers) or facts only. Also lists supported activities and how directly each is modeled. Anywhere not listed is not covered. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Limit to one region id. |
| Name | Required | Description |
|---|---|---|
| schema | Yes | |
| source | Yes | |
| regions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is low; the description still adds real value by disclosing the cost profile ("Free") and the semantic tiering of results (ranked decisions vs facts only). It does not add auth, rate-limit, or pagination context, but none is suggested by 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?
Three short sentences plus a one-word cost note, all front-loaded: coverage scope first, capability tiers second, activities third, and the negative boundary ("Anywhere not listed is not covered") immediately after. Nothing is redundant with the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, no-required-parameter metadata tool with full schema coverage and an output schema, the description supplies everything an agent needs: what is covered, how results are graded, the closed-world boundary, and that it is free. Return-value details are rightly delegated to the output 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?
There is a single optional region parameter with 100% schema description coverage, so the schema already documents its meaning ("Limit to one region id."). The description does not mention the region filter or what an unfiltered call returns, which is the baseline-3 case where structured fields carry the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (KaiCast coverage: regions, spots, supported activities) and what each entry conveys (ranked-decision capability vs facts-only). It is clearly distinguishable from the action-oriented siblings (best_day, get_conditions, recommend_spot), though it never names them explicitly to sharpen the 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?
"Anywhere not listed is not covered" and "Free" give the agent a clear decision rule for interpreting results and a cost signal for when to call it. What is missing is an explicit statement that this should be consulted before recommend_spot/best_day for an unlisted region.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked top picks (max 5) for an activity in one area on one day — by region id, or lat+lon with a radius. Each pick has the best daylight window, why (from the published conditions), a confidence score with its factors, caveats, and a KaiCast spot card. Returns status "not_covered" / "conditions_only" / "activity_not_modeled" honestly instead of guessing. Activities: snorkel (native model), dive, freedive, spearfish (proxy model; spots in water closed to spearfishing are excluded), surf (not modeled). Free during early access.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude, decimal degrees. Use with lon. | |
| lon | No | Longitude, decimal degrees. Use with lat. | |
| date | No | Spot-local day to plan for. Default: today, or tomorrow once today's daylight has passed. Up to 6 days ahead. | |
| spot | No | Spot id, e.g. "hanauma-bay". | |
| limit | No | How many picks (default 3, max 5). | |
| region | No | Region id, e.g. "us-hi-oahu". | |
| activity | Yes | What the user wants to do. | |
| radius_km | No | Search radius around lat/lon in km (default 40, max 100). |
| Name | Required | Description |
|---|---|---|
| picks | Yes | |
| schema | Yes | |
| source | Yes | |
| status | Yes | |
| message | No | |
| coverage | Yes | |
| disclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations: discloses that results cap at 5, shows confidence factors and caveats, and explicitly states it returns honest 'not_covered' / 'conditions_only' / 'activity_not_modeled' statuses instead of guessing. It also flags model fidelity (snorkel native; dive/freedive/spearfish proxy; surf unmodeled), the exclusion of spots in closed waters, and free early-access pricing.
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 core promise (ranked top picks, area, day) before enumerating return fields and activity coverage. The middle sentence is a dense list of returned fields but each item is informative; 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?
An output schema exists so return values needn't be explained, yet the description still usefully characterizes statuses and confidence. With 8 params it covers location modes, activity fidelity, and limit, but leaves the standalone 'spot' parameter and how it combines with region/lat-lon 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 100%, so the schema carries parameter mechanics; the description adds semantic value the schema cannot, notably the native-vs-proxy-vs-unmodeled mapping for each activity enum value. It also reiterates the 5-pick cap and the mutually exclusive region vs lat+lon+radius framing without spelling out precedence.
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 — 'Ranked top picks (max 5) for an activity in one area on one day' — plus the two ways to specify the area (region id, or lat+lon with radius). An agent can immediately tell this returns ranked spot recommendations, distinct from a date-ranking or condition-lookup 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?
Usage context is implied rather than stated: it explains supported activities and location modes, but never says when to choose this over best_day, best_months, get_conditions, or list_coverage. The 'not_covered'/'activity_not_modeled' statuses implicitly signal when the tool can't answer, but the agent must infer the routing rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
best_day1 field changedOutput schema / properties / best / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "properties": {
- "card": {
- "additionalProperties": {},
- "properties": {
- "cta": {
- "additionalProperties": {},
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
- },
- "date": {
- "type": "string"
- },
- "links": {
- "additionalProperties": {},
- "properties": {
- "app": {
- "type": "string"
- },
- "forecast": {
- "type": "string"
- },
- "share": {
- "type": "string"
- }
- },
- "required": [
- "share",
- "app",
- "forecast"
- ],
- "type": "object"
- },
- "score": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "spot_id": {
- "type": "string"
- },
- "spot_name": {
- "type": "string"
- },
- "tier": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "tier_label": {
- "type": "string"
- }
- },
- "required": [
- "spot_id",
- "spot_name",
- "tier",
- "tier_label",
- "score",
- "date",
- "links",
- "cta"
- ],
- "type": "object"
- },
- "caveats": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "confidence": {
- "additionalProperties": {},
- "properties": {
- "label": {
- "type": "string"
- },
- "value": {
- "type": "number"
- }
- },
- "required": [
- "value",
- "label"
- ],
- "type": "object"
- },
- "date": {
- "type": "string"
- },
- "date_label": {
- "type": "string"
- },
- "rank": {
- "type": "number"
- },
- "rating": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "score": {
- "type": "number"
- },
- "spot": {
- "additionalProperties": {},
- "properties": {
- "id": {
- "type": "string"
- },
- "name": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "name"
- ],
- "type": "object"
- },
- "why": {
- "additionalProperties": {},
- "properties": {
- "summary": {
- "type": "string"
- }
- },
- "required": [
- "summary"
- ],
- "type": "object"
- }
- },
- "required": [
- "rank",
- "spot",
- "date",
- "score",
- "rating",
- "why",
- "confidence",
- "caveats",
- "card",
- "date_label"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "card": {
+ "additionalProperties": {},
+ "properties": {
+ "cta": {
+ "additionalProperties": {},
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "label",
+ "url"
+ ],
+ "type": "object"
+ },
+ "date": {
+ "type": "string"
+ },
+ "links": {
+ "additionalProperties": {},
+ "properties": {
+ "app": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "forecast": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "share": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "share",
+ "app",
+ "forecast"
+ ],
+ "type": "object"
+ },
+ "score": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "spot_id": {
+ "type": "string"
+ },
+ "spot_name": {
+ "type": "string"
+ },
+ "tier": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tier_label": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "spot_id",
+ "spot_name",
+ "tier",
+ "tier_label",
+ "score",
+ "date",
+ "links",
+ "cta"
+ ],
+ "type": "object"
+ },
+ "caveats": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "additionalProperties": {},
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "value",
+ "label"
+ ],
+ "type": "object"
+ },
+ "date": {
+ "type": "string"
+ },
+ "date_label": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "rating": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "score": {
+ "type": "number"
+ },
+ "spot": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "why": {
+ "additionalProperties": {},
+ "properties": {
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "summary"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "rank",
+ "spot",
+ "date",
+ "score",
+ "rating",
+ "why",
+ "confidence",
+ "caveats",
+ "card",
+ "date_label"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]best_monthsget_seasonalityrecommend_spot8 fields changedOutput schema / properties / picks / items / properties / card / properties / cta / properties / url / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / picks / items / properties / card / properties / cta / properties / url / typeRemoved value: -"string"Output schema / properties / picks / items / properties / card / properties / links / properties / app / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / picks / items / properties / card / properties / links / properties / app / typeRemoved value: -"string"Output schema / properties / picks / items / properties / card / properties / links / properties / forecast / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / picks / items / properties / card / properties / links / properties / forecast / typeRemoved value: -"string"Output schema / properties / picks / items / properties / card / properties / links / properties / share / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / picks / items / properties / card / properties / links / properties / share / typeRemoved value: -"string"best_day2 fields changedOutput schema / properties / cardsRemoved value: -{
- "items": {
- "additionalProperties": {},
- "properties": {
- "cta": {
- "additionalProperties": {},
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
- },
- "date": {
- "type": "string"
- },
- "links": {
- "additionalProperties": {},
- "properties": {
- "app": {
- "type": "string"
- },
- "forecast": {
- "type": "string"
- },
- "share": {
- "type": "string"
- }
- },
- "required": [
- "share",
- "app",
- "forecast"
- ],
- "type": "object"
- },
- "score": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "spot_id": {
- "type": "string"
- },
- "spot_name": {
- "type": "string"
- },
- "tier": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "tier_label": {
- "type": "string"
- }
- },
- "required": [
- "spot_id",
- "spot_name",
- "tier",
- "tier_label",
- "score",
- "date",
- "links",
- "cta"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / requiredPrevious value: -[
- "schema",
- "status",
- "coverage",
- "cards",
- "disclaimer",
- "source"
-]New value: +[
+ "schema",
+ "status",
+ "coverage",
+ "disclaimer",
+ "source"
+]recommend_spot2 fields changedOutput schema / properties / cardsRemoved value: -{
- "items": {
- "additionalProperties": {},
- "properties": {
- "cta": {
- "additionalProperties": {},
- "properties": {
- "label": {
- "type": "string"
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "url"
- ],
- "type": "object"
- },
- "date": {
- "type": "string"
- },
- "links": {
- "additionalProperties": {},
- "properties": {
- "app": {
- "type": "string"
- },
- "forecast": {
- "type": "string"
- },
- "share": {
- "type": "string"
- }
- },
- "required": [
- "share",
- "app",
- "forecast"
- ],
- "type": "object"
- },
- "score": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "spot_id": {
- "type": "string"
- },
- "spot_name": {
- "type": "string"
- },
- "tier": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "tier_label": {
- "type": "string"
- }
- },
- "required": [
- "spot_id",
- "spot_name",
- "tier",
- "tier_label",
- "score",
- "date",
- "links",
- "cta"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / requiredPrevious value: -[
- "schema",
- "status",
- "coverage",
- "cards",
- "disclaimer",
- "source",
- "picks"
-]New value: +[
+ "schema",
+ "status",
+ "coverage",
+ "disclaimer",
+ "source",
+ "picks"
+]best_day2 fields changedInput schema / properties / region / descriptionPrevious value: -"Region id from list_coverage, e.g. \"us-hi-oahu\"."New value: +"Region id, e.g. \"us-hi-oahu\"."Input schema / properties / spot / descriptionPrevious value: -"Spot id from list_coverage or get_conditions, e.g. \"hanauma-bay\"."New value: +"Spot id, e.g. \"hanauma-bay\"."recommend_spot2 fields changedInput schema / properties / region / descriptionPrevious value: -"Region id from list_coverage, e.g. \"us-hi-oahu\"."New value: +"Region id, e.g. \"us-hi-oahu\"."Input schema / properties / spot / descriptionPrevious value: -"Spot id from list_coverage or get_conditions, e.g. \"hanauma-bay\"."New value: +"Spot id, e.g. \"hanauma-bay\"."best_day2 fields changedInput schema / properties / region / descriptionPrevious value: -"Region id, e.g. \"us-hi-oahu\"."New value: +"Region id from list_coverage, e.g. \"us-hi-oahu\"."Input schema / properties / spot / descriptionPrevious value: -"Spot id, e.g. \"hanauma-bay\"."New value: +"Spot id from list_coverage or get_conditions, e.g. \"hanauma-bay\"."recommend_spot2 fields changedInput schema / properties / region / descriptionPrevious value: -"Region id, e.g. \"us-hi-oahu\"."New value: +"Region id from list_coverage, e.g. \"us-hi-oahu\"."Input schema / properties / spot / descriptionPrevious value: -"Spot id, e.g. \"hanauma-bay\"."New value: +"Spot id from list_coverage or get_conditions, e.g. \"hanauma-bay\"."best_day2 fields changedInput schema / properties / region / descriptionPrevious value: -"Region id from list_coverage, e.g. \"us-hi-oahu\"."New value: +"Region id, e.g. \"us-hi-oahu\"."Input schema / properties / spot / descriptionPrevious value: -"Spot id from list_coverage or get_conditions, e.g. \"hanauma-bay\"."New value: +"Spot id, e.g. \"hanauma-bay\"."recommend_spot2 fields changedInput schema / properties / region / descriptionPrevious value: -"Region id from list_coverage, e.g. \"us-hi-oahu\"."New value: +"Region id, e.g. \"us-hi-oahu\"."Input schema / properties / spot / descriptionPrevious value: -"Spot id from list_coverage or get_conditions, e.g. \"hanauma-bay\"."New value: +"Spot id, e.g. \"hanauma-bay\"."best_dayget_conditionslist_coveragerecommend_spotLive scuba dive planning: forecast windows, best-time climatology, species seasons, 4,800+ sites.
Real-time surf, weather, trail status, volcano, ocean safety, and restaurants for Hawaii.
Nearest NOAA buoy readings, tides and 7-day swell forecast for 150+ surf spots.
Surf trip planner: live 0-100 Strike Scores, 10-day forecasts, and trip picks for 1,100+ spots.
Add one secure layer between your agents and this server.
