Smarter Weather

Find best weather window

find_best_window

Read-onlyIdempotent

Find the optimal time window for an activity based on weather criteria. Scans the forecast and returns daylight-aware periods matching all conditions. Criteria are expressed in the selected units system (default imperial: °F, mph, miles, feet). Example: {"location": "Boulder, CO", "criteria": {"min_temperature": 55, "max_wind_speed": 15, "max_precipitation_probability": 20}, "hours": 72, "activity_duration_hours": 3}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lat`	No	Latitude in decimal degrees (-90 to 90). Most tools also accept a `location` place-name string instead of lat/lon.
`lon`	No	Longitude in decimal degrees (-180 to 180). For continental US use negative values (west of the prime meridian).
`hours`	No	Hours to search. Default 72.
`units`	No	Unit system for all values in the request and response: imperial (°F, mph, inches), metric (°C, km/h, mm), or si (K, m/s, mm). Defaults to imperial.	imperial
`activity`	No	Free-form activity to rate the windows for (e.g. "afternoon golf"). Accepted even when rating is off so clients can send it.
`criteria`	Yes	Weather criteria defining acceptable conditions (all optional).
`location`	No	Free-text place: city ("Denver"), city+state ("Portland, OR"), US ZIP ("50219"), or "lat,lon" ("39.74,-104.99"). Provide either this OR explicit lat+lon, not both.
`daylight_only`	No	Only consider daylight hours (sunrise to sunset). Default true.
`activity_duration_hours`	No	Minimum consecutive hours meeting criteria. Default 2.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`units`	Yes
`message`	No
`windows`	Yes
`location`	Yes
`sun_times`	No
`daylight_only`	Yes
`criteria_applied`	Yes
`activity_duration_hours`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 22, 2026

addedInput schema / properties / activity

Added value: +{
+  "description": "Free-form activity to rate the windows for (e.g. \"afternoon golf\"). Accepted even when rating is off so clients can send it.",
+  "maxLength": 200,
+  "type": "string"
+}

addedOutput schema / properties / windows / items / properties / limiting_factor

Added value: +{
+  "enum": [
+    "wind",
+    "precip",
+    "temperature",
+    "visibility",
+    "storms",
+    "none"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / windows / items / properties / rating

Added value: +{
+  "enum": [
+    "unworkable",
+    "poor",
+    "workable",
+    "good",
+    "ideal"
+  ],
+  "type": "string"
+}

First observedJul 14, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds behavioral context beyond annotations: it discloses that it scans the forecast, returns daylight-aware periods, requires all conditions to match, and specifies the units system. It doesn't describe edge cases like no matching window or the exact optimization objective, but given annotation coverage, the added detail is sufficient for a 4.

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

Conciseness5/5

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

The description is concise and well-structured: a one-sentence purpose, a behavior statement, a units note, and an example. It is front-loaded with the core purpose, and every sentence contributes meaning. The example is compact yet informative, covering key parameter usage. No filler words or redundancy.

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 9 parameters and a nested object, the description covers the essential concepts (criteria, units, daylight-awareness, example) without needing to explain every field since the schema is fully documented. An output schema exists, so return-value details are not required. The description is complete enough for an agent to understand the tool's capabilities, though it could briefly clarify what 'optimal' means in terms of ranking windows.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explicitly noting that criteria are expressed in the selected units system and by providing a concrete example covering multiple criteria and parameters. This helps agents understand how to structure the `criteria` object and how units apply, going beyond the schema's per-field descriptions.

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?

The description clearly states the tool's purpose: 'Find the optimal time window for an activity based on weather criteria.' It names a specific verb ('find') and resource ('optimal time window'), and distinguishes itself from siblings by focusing on window selection rather than raw data retrieval. The additional phrase 'Scans the forecast and returns daylight-aware periods matching all conditions' further clarifies the unique functionality.

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?

The description provides clear usage context: it is for finding time windows based on weather criteria, which implies when an agent would choose this over raw forecast tools. It doesn't explicitly mention alternatives or when-not-to-use, but the stated purpose is distinct enough that an agent can infer appropriate usage. No exclusions are given, but the clarity of the purpose earns a solid 4.

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

All Smarter Weather tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.