Skip to main content
Glama
Sign In

SeekSat

by com.seeksat
OverviewDiscussionsAdmin

Pass weather

get_pass_weather
Read-onlyIdempotent

Cloud-cover forecast (Open-Meteo and MET Norway) and the chance of a clear view for a location at one time, such as a pass's peak. The forecast reaches about 7 to 16 days ahead. viewingProbability is the clear-sky chance (0-1), blended toward 0.5 the further ahead the time is, since forecasts lose skill. When there is no forecast for that time (in the past, beyond the forecast, a time it cannot read, or the forecast could not be fetched) the result is available:false with a reason, never a stand-in number.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "time": "<time>"
    },
    "name": "get_pass_weather"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNoobserver latitude in decimal degrees, north positive (-90 to 90). Give it with lon, or give location instead.
lonNoobserver longitude in decimal degrees, east positive and west negative (-180 to 180).
timeYesthe time to check, e.g. a pass's peak. ISO 8601 with Z or an offset, e.g. "2026-11-14T21:00:00-06:00"; a time with no offset, e.g. "2026-11-14T21:00", is read in the observer's time zone, and the result echoes how it was read (interpretedAs). A local time the clocks skip at a daylight-saving change is moved forward, with a note.
locationNowhere the observer is, when lat and lon are not given (they win when both are): a Maidenhead grid square (EN52, EN52ve, EN52ve12), coordinates in any common form ("41.88, -87.63", "41.88N 87.63W", "41°52'48"N 87°37'48"W", a Google Maps link or geo: URI), all read locally, or a place name (city, address, landmark) looked up with OpenStreetMap. Prefer lat and lon, or a grid square, when you have them: a place name is a network lookup.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations (which already declare readOnly/idempotent/openWorld), it discloses the upstream data sources, the effective forecast horizon, that viewingProbability is deliberately regressed toward 0.5 with lead time, and that failure yields available:false with a reason rather than a fabricated value. That is exactly the behavioral context annotations cannot carry.

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?

Three sentences, front-loaded with what is returned and how far ahead it is valid, then the failure contract. The parenthetical source list and the DST/no-offset detail make the sentences dense, but nothing is redundant.

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 no output schema, the description does the necessary work by naming viewingProbability's scale and meaning and the available:false + reason error shape. It stops short of describing the cloud-cover fields themselves, so the return surface is only partially covered.

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%, and the schema already explains lat/lon precedence over location, grid-square and coordinate formats, and ISO-8601 time reading. The description adds only the "such as a pass's peak" hint for the time parameter, so it sits at the baseline where structured fields do the work.

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?

"Cloud-cover forecast ... and the chance of a clear view for a location at one time" names a specific verb-and-resource pair (forecast retrieval) plus the derived output (viewing probability), and the example "such as a pass's peak" separates it from the pass-computation siblings like get_pass_chart or find_passes.

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 establishes clear operating context: one location, one time, forecasts reach roughly 7-16 days ahead, and out-of-range times return a failure result rather than a number. It does not name a sibling to use for other time ranges or for multi-time queries, so no explicit exclusion is stated.

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

All SeekSat toolsInspect
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.

Resources