WindWise MCP

Detailed wind forecast

get_wind_forecast

Read-onlyIdempotent

Retrieve hourly wind speed, gusts, and direction for up to 7 days with daily summaries to identify peak wind times and plan daylight-hour outings.

Instructions

Hourly wind speed, gusts and direction in knots for up to 7 days, plus a per-day summary (average, peak and peak time, strongest gust, prevailing direction). Only hours from now on are included. Restrict to daylight with start_hour/end_hour (local time). Use this to answer 'when is the wind strongest' 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_wind_forecast"
  }
}

Input Schema

Name	Required	Description
`days`	No	Number of days to cover, starting now (1-7). Hours already past are left out.
`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.
`start_hour`	No	Start of the time range, local hour 0-23 (inclusive).

Output Schema

Name	Required	Description
`daily`	Yes
`hours`	Yes
`units`	Yes
`caveat`	Yes
`hourly`	Yes
`location`	Yes
`attribution`	Yes	Required credit for the data source.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A3.9/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, open-world), and the description adds genuinely useful behavior the annotations cannot: units (knots), the 7-day ceiling, the rule that only future hours are returned, and that hour bounds are local time. It says nothing about forecast resolution, data source, or rate limits, which keeps it out of the top band.

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?

The output content is front-loaded in the first sentence and each following sentence adds a distinct constraint (future-only hours, daylight filtering, intended question). Mild overlap with what the schema already states about days and local hours keeps it from a 5.

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 an output schema present, the description needn't explain return values, and it is complete on the calling side: units, time horizon, future-only restriction, and local-time hour bounds are all stated. Missing are only secondary details such as how location is resolved relative to coordinates and any forecast model/resolution caveats.

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 each parameter is already documented including the local-hour semantics and the 1-7 day bound. The description largely restates those facts (up to 7 days, daylight via start_hour/end_hour, local time) rather than adding new parameter meaning, so the baseline 3 applies.

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

Purpose4/5

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

The first sentence names a specific verb+resource with concrete output content — hourly wind speed, gusts, direction in knots plus a per-day summary — so an agent knows exactly what it returns. It does not, however, explicitly distinguish itself from likely overlapping siblings such as find_wind_windows or get_weather, leaving that comparison to inference.

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?

It gives a clear use case ("when is the wind strongest" questions) and a concrete narrowing instruction (restrict to daylight with start_hour/end_hour). It stops short of stating when NOT to use it or naming an alternative tool for wind-window searches, so the 4 rather than 5.

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

Deploy Server