WindWise MCP

Find rideable wind windows

find_wind_windows

Read-onlyIdempotent

Finds continuous time windows when wind matches activity presets or custom speed, gust, direction, and time criteria, returning the best window and why hours were rejected.

Instructions

Find continuous time windows from now on when the wind matches the criteria: an activity preset (e.g. dinghy_sailing) or explicit min/max knots and max gusts, plus allowed directions and time of day. Returns each window with its average/peak wind and direction, the best window, and, when nothing matches, why each hour was rejected. Use for questions like 'will there be enough wind for wing foiling tomorrow?' or 'when can I go dinghy sailing this week?'.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_wind_windows"
  }
}

Input Schema

Name	Required	Description
`days`	No	Number of days to cover, starting now (1-7). Hours already past are left out.
`activity`	No	Preset wind range for an activity (wing_foiling = 12+ kn, dinghy_sailing = 10-18 kn). Explicit min/max/gust values override the preset.
`end_hour`	No	End of the time range, local hour 1-24 (exclusive): 18 means up to 18:00.
`latitude`	No	Latitude in decimal degrees.
`location`	No	Place name, optionally with region/country to disambiguate, e.g. "Bucerias, Mexico" or "Springfield, US". Ignored for lookup when latitude and longitude are given (then only a label).
`longitude`	No	Longitude in decimal degrees.
`directions`	No	Only accept wind coming FROM these 16-point compass directions, e.g. ["W","WSW","SW"] for a beach facing south-west. Omit to accept any direction.
`start_hour`	No	Start of the time range, local hour 0-23 (inclusive).
`max_gust_knots`	No	Reject hours whose gusts exceed this, in knots.
`max_wind_knots`	No	Maximum sustained wind in knots. Defaults to the activity preset, or no upper limit.
`min_wind_knots`	No	Minimum sustained wind in knots. Defaults to the activity preset, or 12 kn.
`min_window_hours`	No	Ignore stretches of good wind shorter than this many hours (default 2).
`exclude_thunderstorms`	No	Never count hours with forecast thunderstorms as rideable.

Output Schema

Name	Required	Description
`found`	Yes
`notes`	Yes
`windows`	Yes
`criteria`	Yes
`location`	Yes
`bestWindow`	Yes
`attribution`	Yes	Required credit for the data source.
`windowCount`	Yes
`whyNoWindows`	No	Count of rejected hours by reason.
`totalRideableHours`	Yes
`strongestHourInRange`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, open-world behavior, and the description adds real value beyond that: it discloses that results include a best window and, on failure, a per-hour rejection rationale. It also notes windows start 'from now on', clarifying that past hours are excluded. It does not discuss rate limits, forecast source, or timezone handling, keeping it below 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.

Conciseness4/5

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

Front-loads the core action and return shape in the first sentence, then adds example questions that earn their place by illustrating intent. It is a dense single paragraph, but no sentence is redundant; a short bullet or sentence break would improve scanability slightly.

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

Completeness4/5

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

With 13 parameters, an output schema, and read-only annotations, the description covers the essential contract: what constitutes a window, what is returned, and what happens when nothing matches. Minor gaps remain around timezone/local-hour semantics and forecast horizon assumptions, but the structured fields cover most of that burden.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented, including preset ranges, defaults, and override precedence. The description only paraphrases that criteria come from a preset or explicit min/max knots, max gusts, directions, and time of day, adding no syntax or nuance beyond the schema; baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource: find continuous time windows from now on where wind satisfies user criteria. The description makes clear this is a window-finding/screening tool rather than a raw forecast dumper, which is enough to separate it from get_wind_forecast or get_weather even without naming them.

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

Usage Guidelines4/5

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

Gives concrete triggering questions ('will there be enough wind for wing foiling tomorrow?', 'when can I go dinghy sailing this week?') and explains the two ways to specify criteria (activity preset vs explicit thresholds). It does not explicitly say when to prefer a sibling like get_wind_forecast for raw hourly data, so it stops short of full alternative routing.

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

Deploy Server