Skip to main content
Glama

OhMyWind

by fr.ohmywind

get_marine_forecast

Read-onlyIdempotent

Fetch wind (and sea, when available) for a point and time window.

    Args:
        lat: latitude in degrees.
        lon: longitude in degrees.
        start: ISO-8601 datetime, timezone-aware (e.g. "2026-05-01T06:00:00+00:00").
        end: ISO-8601 datetime, timezone-aware.
        models: optional list of model names; defaults to AROME for the Med.

    Pass a point at sea. Over land Open-Meteo still returns wind, but
    every sea value comes back null, so the ``sea`` array is present and
    empty of information rather than absent.

    Note: the first request after inactivity may incur ~5s of cold-start.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYes
latYes
lonYes
startYes
modelsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses important runtime behaviors: cold-start latency after inactivity, the fact that sea values are null over land while the array remains present, and that sea information is only returned 'when available.' These details are not available from the schema or annotations and materially affect how an agent interprets results.

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 well organized: a one-sentence purpose, a compact Args block, a usage caveat about land vs. sea, and a latency note. Every sentence adds useful information for invoking the tool correctly, with no filler or duplication of schema defaults.

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?

Given the output schema is present, return values do not need to be spelled out. The description covers input formats, default model behavior, geographic limitations, and a performance characteristic. This is a complete picture for an agent to select and call the tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden for parameter meaning—and it does so comprehensively. It explains latitude/longitude in degrees, ISO-8601 timezone-aware format for start/end with a concrete example, and the models parameter's optional nature with its AROME default for the Med. This goes well beyond the bare schema field names.

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 opens with a specific verb and resource: 'Fetch wind (and sea, when available) for a point and time window.' This clearly distinguishes the tool as a marine forecast retrieval operation and aligns with its name and title. Unlike vague or tautological descriptions, it tells the agent exactly what data type and spatial/temporal scope are involved.

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 context for when to use the tool: 'Pass a point at sea' and the discussion of land behavior ('Over land Open-Meteo still returns wind, but every sea value comes back null') help the agent decide whether this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusionary guidance.

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

All OhMyWind toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool owns a clearly distinct responsibility: point forecasts (get_marine_forecast), boat archetype metadata (list_boat_archetypes), route/window planning (plan_passage), and methodology documentation (read_me). The only plausible overlap between forecasting and passage planning is explicitly resolved by routing instructions inside plan_passage. An agent should rarely mis-select among them.

Naming Consistency5/5

All four names are lowercase snake_case with a verb-first structure: get_, list_, plan_, read_. While read_me is idiomatic rather than a resource noun, the verb-object pattern is consistent and predictable across the whole set.

Tool Count5/5

Four tools is a well-scoped size for a niche marine routing/wind server. Every tool earns its place in the workflow, and none are redundant or missing to the point of feeling thin.

Completeness4/5

The core user journey is covered: fetch conditions, select a boat archetype, plan a passage with departure-window comparison, and read the methodology. Minor gaps remain—no land/route validation tool and no explicit model catalog—but the descriptions document these limitations and let agents work around them.

Resources