WindWise MCP

Session summary for a day

get_weather_summary

Read-onlyIdempotent

Decide whether to head out on the water by combining weather and marine forecasts into a one-day briefing with wind window, sea state, rain risk, and a go/marginal/no-go verdict.

Instructions

One-call briefing for a water-sports day at a place: weather, temperature range, rain and thunderstorm risk, wind summary and best wind window, waves and sea state, and a go / marginal / no_go verdict with reasons. Combines the weather and marine forecasts. For today, only the remaining hours count. Set activity (e.g. dinghy_sailing) to judge the day for that wind range. Start here for 'should I go out tomorrow?' questions.

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": "get_weather_summary"
  }
}

Input Schema

Name	Required	Description	Default
`day`	No	Which day: "today", "tomorrow" or a local date "YYYY-MM-DD" (up to 15 days ahead).	today
`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).

Output Schema

Name	Required	Description
`date`	Yes
`wind`	Yes
`hours`	Yes
`notes`	Yes
`marine`	Yes
`reasons`	Yes
`verdict`	Yes
`weather`	Yes
`activity`	Yes
`location`	Yes
`attribution`	Yes	Required credit for the data source.
`windRangeKn`	Yes
`windWindows`	Yes
`bestWindWindow`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the description's added value is the aggregation semantics: it fuses two underlying forecasts, truncates today to remaining hours, and returns a three-way verdict with reasons. That is genuinely useful context an agent cannot infer from the annotations. It does not discuss ambiguity handling for location resolution or failure modes, keeping it below the top mark.

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-loaded with the deliverable (what the briefing contains), then the mechanism, then the usage cue. Sentences are dense but each carries information. The long enumeration of outputs is justified for a summary tool, though it could be tightened slightly.

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

Completeness5/5

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

For a 12-parameter aggregation tool with full schema coverage, an output schema, and read-only annotations, the description supplies everything an agent needs: what is returned, that today is truncated, how activity presets affect the verdict, and when to reach for it first. No material gap remains for correct selection or invocation.

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 all 12 parameters are already documented, including the activity presets and the override behavior. The description's only parameter-related addition is restating that activity selects the wind range to judge against, which the schema already spells out with knot values. Baseline 3 is appropriate since the schema does the heavy lifting.

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 ('One-call briefing for a water-sports day') and enumerates exactly what the briefing contains: weather, temperature range, rain/thunderstorm risk, wind summary with best window, sea state, and a go/marginal/no_go verdict. It also distinguishes itself from siblings by saying it 'Combines the weather and marine forecasts', so an agent knows this is the aggregated layer rather than get_weather or get_marine_conditions.

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 an explicit entry-point instruction: 'Start here for "should I go out tomorrow?" questions,' which routes the agent away from the raw component tools. It also clarifies the today-case behavior ('only the remaining hours count') and how to pick the activity preset. It stops short of naming when to prefer the sibling detail tools (e.g. get_wind_forecast for hour-by-hour data), so no explicit exclusions.

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

Deploy Server