OhMyWind

by fr.ohmywind

Server Details

Sailing passage planner for any coast, with high-precision tides on the French Atlantic.

Status: Healthy
Last Tested: 2026-08-22 06:32
Transport: Streamable HTTP
URL
Repository: qdonnars/ohmywind
GitHub Stars: 6
Server Listing: OhMyWind

Glama MCP Gateway

Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.

MCP client

Glama

MCP server

Full call logging

Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.

Tool access control

Enable or disable individual tools per connector, so you decide what your agents can and cannot do.

Managed credentials

Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.

Usage analytics

See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.

100% free. Your data is private.

Tool Definition Quality

A4.6/5.0

Tool DescriptionsA

Average 4.5/5 across 4 of 4 tools scored.

Server CoherenceA

Disambiguation5/5

Each tool has a clearly distinct purpose: point forecast, listing archetypes, passage planning, and methodology reference. There is no overlap in their core functions, and plan_passage's references to other tools do not create ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: get_marine_forecast, list_boat_archetypes, plan_passage, read_me. The verbs and nouns are distinct and predictable.

Tool Count5/5

Four tools is well-scoped for a specialized wind and route planning server. Each tool covers an essential, non-overlapping capability without redundancy.

Completeness5/5

The tool surface covers the full user workflow: checking weather, selecting a boat archetype, planning a passage in single or multi-window mode, and reading the methodology. No obvious missing operations for the domain.

Available Tools

4 tools

get_marine_forecastA

Read-only

Inspect

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.

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

ParametersJSON Schema

Name	Required	Description	Default
`end`	Yes
`lat`	Yes
`lon`	Yes
`start`	Yes
`models`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

Tool Definition Quality

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: the cold-start delay, the 'when available' caveat for sea data, and the default model (AROME for the Med). No contradictions with annotations.

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 description is front-loaded with purpose, followed by a compact Args section and a note. Every sentence adds value, though the Args block could be slightly more terse. Overall well-structured and not overlong.

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?

Given the tool's complexity, the description covers inputs, defaults, and a behavioral caveat. An output schema exists, so return values need not be described. It lacks explicit mention of output format, but that is supplied by the output schema.

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%, and the description fully compensates by explaining each parameter: latitude/longitude in degrees, ISO-8601 timezone-aware datetimes with an example, and the optional models list with a default. This goes well beyond the bare schema.

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 a specific action ('Fetch wind (and sea, when available)') on a specific resource (marine forecast) for a point and time window. This distinguishes it from siblings like 'list_boat_archetypes' and 'plan_passage'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (for point/time forecasts) but does not explicitly mention when not to use it or mention alternatives. It provides context like default model and cold-start, but no direct comparison to sibling tools.

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

list_boat_archetypesA

Read-only

Inspect

List the 7 boat archetypes with descriptive metadata.

The LLM (or user) maps a commercial model (e.g. "Sun Odyssey 32") to one of these archetypes from the metadata — there is no server-side mapping.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

Tool Definition Quality

A4.5/5.0

Behavior4/5

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

Annotations already set readOnlyHint=true and openWorldHint=false. The description adds the concrete number of archetypes (7) and the critical behavioral detail that mapping is client-side and not performed by the server. This enriches the agent's understanding beyond the annotation flags.

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?

Two tight sentences. The first is a direct, front-loaded declaration of the tool's function. The second provides essential context without unnecessary words. No redundancy.

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?

The tool is a simple fixed-list read with no parameters and an output schema present. The description covers the tool's purpose, the data it returns (7 archetypes with metadata), and the client-side mapping responsibility. Since the output schema exists, return field details don't need to be in the description. Fully adequate.

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?

With zero parameters, the schema is trivially covered at 100%. The description adds no parameter-level detail (none needed), so the baseline of 4 applies.

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 'List the 7 boat archetypes with descriptive metadata' – a specific verb (List), a precise resource (7 boat archetypes), and the outcome (descriptive metadata). It clearly differentiates from siblings like get_marine_forecast and plan_passage, which serve different marine planning functions.

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 second sentence gives direct usage guidance: the LLM/user maps a commercial model to an archetype from the metadata, and there is no server-side mapping. This tells the agent when to use the tool (to obtain archetype data for client-side mapping) and what not to expect (no server-side mapping). However, it doesn't name explicit alternatives or exclusion cases, so it's slightly below the top bar.

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

plan_passageA

Read-only

Inspect

Plan an A→B passage. Compare departure windows by default; pin a single departure only when the user gives an explicit time.

    ## Tool routing: read this first

    Before calling, classify the user's question:

    1. **Pure weather lookup at a point** ("y aura-t-il du vent à Cassis
       samedi à 14h ?", "quelles vagues dimanche au cap Sicié ?"): call
       ``get_marine_forecast`` and answer in text. Do NOT call
       ``plan_passage``: there's no route to plan.

    2. **Trajet question with a flexible date** ("Marseille → Porquerolles
       ce week-end", "demain ou après-demain", "dans les prochains jours"):
       call ``plan_passage`` in **compare-windows mode**, passing
       ``latest_departure`` (e.g. earliest+48h) and ``sweep_interval_hours``
       (3 or 6 typically) so the user sees several departure scenarios
       side-by-side. Then pick 2-3 good ones and let the user choose.
       This is the **default** for trajet planning: same API cost as a
       single passage thanks to cache prewarm, much more value.

    3. **Trajet with a precise hour pinned by the user** ("je pars demain
       à 8h", "départ Saturday 9am"): call ``plan_passage`` in single
       mode (no ``latest_departure``). Used for the final "show me the
       detailed plan for THIS departure" view, often after step 2.

    4. **Methodology question** ("comment c'est calculé ?",
       "quelle efficacité par défaut ?"): call ``read_me``.

    Rule of thumb: if the user does NOT give an exact hour, prefer
    compare-windows. The widget renders one of the windows by default
    and the chat lets the user pick another.

    ## Returned payload

    Single mode:

    - ``passage``: per-segment timing report (distance_nm, duration_h,
      model used, segments[] with TWS/TWA/boat_speed/Hs, warnings).
    - ``complexity``: 1-5 difficulty score with wind/sea breakdown and a
      human-readable rationale.
    - ``openwind_url``: deep-link to ohmywind.fr/plan that renders the
      same passage in the standalone web app.

    Compare-windows mode (``latest_departure`` set):

    - ``mode``: ``"multi_window"``.
    - ``sweep``: ``earliest`` / ``latest`` / ``interval_hours`` /
      ``window_count``.
    - ``windows[]``: each entry has ``departure``, ``arrival``,
      ``duration_h``, ``distance_nm``, ``complexity`` (level + label +
      rationale), ``conditions_summary`` (tws_min/max, predominant sail
      angle, hs_min/max), ``warnings``, ``passage`` (full per-segment
      report), ``complexity_full`` (full score), ``openwind_url``.
    - ``meta_warnings``: top-level notes ("3 fenêtres ignorées …").

    ## How it renders

    On hosts that support MCP Apps (Claude, Claude Desktop, ChatGPT, VS
    Code Copilot, Goose, Postman, MCPJam), the response is automatically
    accompanied by an interactive widget: the live ohmywind.fr/plan view
    served via the ``ui://openwind/plan-passage`` resource declared on
    this tool's ``_meta``. The widget reads ``openwind_url`` from the
    structured output and embeds the matching plan view as an iframe.

    On hosts without MCP Apps support (Cursor, Le Chat, terminal), present
    a short text summary of the result (route, ETA, complexity, warnings)
    and offer ``openwind_url`` as the "View full plan →" link.

    ## ALWAYS include the openwind_url(s) in your text reply

    Even when the widget renders inline, the user wants the link spelled
    out so they can open the full app, share it, or bookmark it. Treat
    this as a hard requirement, not a fallback:

    - **Single mode**: end your reply with a Markdown link built from the
      ``openwind_url`` field, e.g. ``[Voir le plan détaillé →](<openwind_url>)``.
      Always use that value verbatim, never a URL you compose yourself: it
      points at the environment this server is configured for, which is not
      always the production site.
    - **Compare-windows mode**: list 2-4 of the most relevant windows
      and give each its own link, e.g.
      ``- Sam 2 mai 09h · 11h12 · ⚡2/5 · [voir →](url)``.
      The user picks one from the chat, not the widget.

    Phrase the link with intent ("voir le plan détaillé", "ouvrir cette
    fenêtre dans l'app"), not just a bare URL: the user should know
    what clicking does.

    ## Args

        waypoints: list of ``{"lat": ..., "lon": ...}`` dicts (>=2). Caller
            keeps the polyline off land: add intermediate waypoints to
            skirt capes and peninsulas.
        departure: ISO-8601 datetime, timezone-aware.
        archetype: one of ``list_boat_archetypes()`` names.
        efficiency: multiplier on polar speed. ``0.85`` racing, ``0.75``
            cruising (default), ``0.65`` loaded family cruising, ``0.55``
            heavy seas / fouled hull.
        segment_length_nm: target sub-segment length. Default 10 nm
            balances precision vs Open-Meteo budget; drop to 5 for tight
            coastal work, raise to 20 for long offshore legs.
        model: wind model. Default ``"auto"`` tries AROME (≤48 h) →
            ICON-EU (≤5 d) → ECMWF IFS 0.25° (≤10 d) → GFS (≤16 d).
            Pass an explicit name to bypass.
        max_hs_m: optional max significant wave height (meters) over the
            route: pass it if you have a sea-state estimate from
            ``get_marine_forecast`` and want it factored into the score.
            Defaults to wind-only scoring.
        motor_threshold_kn: optional sail-speed floor (knots) under which
            the simulator switches to engine power. Must be paired with
            ``motor_speed_kn`` (either alone is ignored). Typical value
            2 kn: sailors fire up the engine rather than crawl in light
            wind. Leave unset for 100% sail. Range (0, 10].
        motor_speed_kn: optional speed under engine (knots) applied to
            segments where the sail estimate falls under
            ``motor_threshold_kn``. Typical 5-6 kn for a cruising boat.
            Range (0, 12].
        min_upwind_twa_deg: optional minimum sailable TWA (degrees)
            overriding the archetype's own value (42-50 deg depending on
            the boat). Pass it when you know the boat points better or
            worse than the archetype suggests. Range [25, 70].

    ## Compare-windows mode (latest_departure set)

    When ``latest_departure`` is provided, the tool switches into a
    window-comparison call: it walks departure times from ``departure``
    up to ``latest_departure`` every ``sweep_interval_hours`` (default
    1 h). Returns ``{"mode": "multi_window", "sweep": {...}, "windows":
    [...]}`` instead of the single-passage payload. Each window contains
    ``departure``, ``arrival``, ``duration_h``, ``distance_nm``,
    ``complexity``, ``conditions_summary``, ``warnings``, and its own
    ``openwind_url``.

    ``target_eta``: optional ISO-8601 datetime. When set, only windows that
    arrive within ±2 h of the target are returned. If none match, all
    windows are returned with a ``meta_warnings`` note.

    ## Failure modes

    Raises ``ForecastHorizonError`` if the chosen model's horizon doesn't
    cover the passage and ``model != "auto"``. The error message names the
    failing model and suggests longer-range alternatives.

ParametersJSON Schema

Name	Required	Default
`model`	No	auto
`max_hs_m`	No
`archetype`	Yes
`departure`	Yes
`waypoints`	Yes
`efficiency`	No
`target_eta`	No
`motor_speed_kn`	No
`latest_departure`	No
`segment_length_nm`	No
`min_upwind_twa_deg`	No
`motor_threshold_kn`	No
`sweep_interval_hours`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

Tool Definition Quality

A4.9/5.0

Behavior5/5

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

Despite readOnlyHint/openWorldHint annotations, the description adds substantial behavior: default compare-windows mode, rendering behavior across host types, hard requirement to include openwind_url, parameter coupling (motor_threshold_kn/motor_speed_kn), and ForecastHorizonError failure mode. No contradiction with annotations.

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?

Well-structured with headers, bold labels, and a front-loaded summary, but there is redundancy: the compare-windows payload fields are listed twice, in 'Returned payload' and again in 'Compare-windows mode.' Long, but almost every section earns its place.

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 complex 13-parameter tool with routing decisions and a custom multi-window mode, the description covers input semantics, output payload, rendering behavior, URL requirements, and failure modes. An output schema exists, but the description still adds critical context without needing to explain basic return types.

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 coverage is 0% with 13 params, but the description documents every parameter with defaults, ranges, units, examples, and coupling constraints (e.g., motor_threshold_kn must be paired with motor_speed_kn). This fully compensates for the schema's bare types.

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?

Opens with a specific verb+resource: 'Plan an A→B passage.' It also distinguishes itself from siblings by stating when to use get_marine_forecast and read_me, and separates compare-windows vs single-departure modes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides an explicit routing section with four numbered classification cases, naming alternatives (get_marine_forecast, read_me) and a rule of thumb for when to prefer compare-windows. This is exactly the when-to-use vs when-not-to-use guidance expected.

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

read_meA

Read-only

Inspect

Return OhMyWind's calculation methodology as Markdown.

    Call this when the user asks how passage timing, complexity, or
    boat speed are computed (e.g. "comment c'est calculé ?",
    "what assumptions does the model use?", "is tacking modelled?").

    The returned text covers: polar lookup, default efficiency 0.75,
    VMG / tacking correction, wave derate, single-pass timing,
    compare-windows mode semantics, Mediterranean simplifications
    (tides, currents), and what is intentionally NOT modelled in V1.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

Tool Definition Quality

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows it is a safe read. The description adds value by enumerating exactly which aspects of the methodology are covered (polar lookup, efficiency, VMG/tacking, wave derate, etc.) and explicitly notes what is intentionally NOT modeled. This goes beyond annotation basics and gives useful behavioral context.

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 but information-dense. First sentence states purpose, second provides usage guidance with examples, third lists the coverage topics. Each sentence earns its place, and the bullet-like enumeration is easy to parse. No redundant phrasing or fluff.

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 tool's simple nature (no params, read-only, returns Markdown), the description is complete: it states what it returns, when to use it, and what content to expect. The presence of an output schema also means return values don't need deep explanation. There is no ambiguity about scope or limitations.

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?

The tool has zero parameters, and the schema coverage is trivially 100% (empty properties). With no parameters to describe, the baseline is 4. The description does not need to add parameter details, and it doesn't. This is appropriate.

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: 'Return OhMyWind's calculation methodology as Markdown.' This clearly distinguishes the tool from siblings like plan_passage or get_marine_forecast, which serve different purposes. The scope is precise: covering calculation methodology, not operational data.

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 explicitly states when to call the tool ('Call this when the user asks how passage timing, complexity, or boat speed are computed') and gives concrete example queries. It does not name alternatives or explicitly state when-not-to-use, but the context is clear enough that an agent can infer the appropriate use case.

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

Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "maintainers": [{ "email": "your-email@example.com" }]
}

The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Servers

Garmin Sailing MCP
Sports Fitness Tracking Weather Services
vinicius-saraiva
F
license
Not graded
quality
D
maintenance
Turns your Garmin watch into a sailing analytics tool by combining GPS data from Garmin Connect with historical weather data, providing insights like speed, VMG, wind conditions, and interactive maps.
Updated 5 months ago (2026-03-12 01:54 UTC)
2
Shipxy MCP Server
Location Services Travel & Transportation Weather Services
garrettXu
A
license
Not graded
quality
C
maintenance
A fully MCP-compliant, open-source maritime data service that provides real-time vessel tracking, port information, route planning, and weather/tide data for maritime applications.
Updated 2 months ago (2026-06-11 09:47 UTC)
13
MIT
windscout-mcp
Weather Services Web Scraping
jwillert
A
license
A
quality
C
maintenance
MCP server for wind forecasts, live measurements, wave forecasts, and tides, enabling kite and surf spot checks via AI assistants.
Updated 2 months ago (2026-06-21 16:53 UTC)
5
10
MIT
mcp-maritime
Weather Services Travel & Transportation
Ryo-Suzukii
A
license
Not graded
quality
C
maintenance
Provides real-time maritime weather data, tropical cyclone warnings, and route calculations for AI agents.
Updated 2 months ago (2026-06-11 00:15 UTC)
MIT

View all MCP Servers

Try in Browser

OhMyWind

Server Details

Tool Definition Quality

Available Tools

Output Schema

Tool Definition Quality

Output Schema

Tool Definition Quality

Output Schema

Tool Definition Quality

Output Schema

Tool Definition Quality

Discussions

Related MCP Servers

Garmin Sailing MCP

Shipxy MCP Server

windscout-mcp

mcp-maritime

Your Connectors

Resources