OhMyWind

Server Details

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

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.2% over 46 days
Last Tested: 2026-10-02 01:33
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: qdonnars/ohmywind
GitHub Stars: 10
Server Listing: OhMyWind

TDQS

A4.7/5.0

Scored 2026-09-18 20:01 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct job: point weather lookup, boat archetype metadata, passage planning, and methodology docs. plan_passage even contains explicit routing guidance that steers pure weather questions toward get_marine_forecast, so there is no real ambiguity.

Naming Consistency5/5

All tool names use lowercase snake_case with a leading verb: get_, list_, plan_, read_. The pattern is predictable and easy to infer, with read_me being the only slightly informal name but still consistent in style.

Tool Count5/5

Four tools is compact but well-scoped for a wind and passage planning server: one lookup, one metadata list, one main planning action, and one documentation tool. Each tool earns its place and there is no redundancy.

Completeness5/5

The tool surface covers the full core workflow: check conditions at a point, select a boat archetype, plan an A→B passage with optional departure-window comparison, and understand the methodology. The lack of land checking is documented as an explicit design boundary rather than an accidental omission.

Available Tools

4 tools

get_marine_forecastA

Read-onlyIdempotent

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.

    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.

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

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.

list_boat_archetypesA

Read-onlyIdempotent

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

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds valuable behavioral context: the tool returns exactly 7 archetypes with descriptive metadata, and that the mapping responsibility lies with the caller rather than the server. This goes beyond what annotations provide.

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 two sentences with no redundancy. The primary action and resource are front-loaded, and the second sentence adds essential context about the mapping workflow. Every word 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?

Given there are no parameters and an output schema exists to describe the return value, the description is fully sufficient. It states what the tool returns (7 archetypes with metadata), why it exists (client-side mapping), and the key limitation (no server-side mapping). No further details are needed for a correct invocation.

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, so there is no parameter semantics burden. The description correctly focuses on the output and purpose rather than trying to document nonexistent inputs. A baseline of 4 is appropriate for a parameterless tool with full schema coverage.

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 starts with a specific verb and resource: 'List the 7 boat archetypes with descriptive metadata.' It clearly distinguishes this tool from siblings like get_marine_forecast and plan_passage by identifying the resource as archetype metadata. The purpose is unambiguous.

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 clearly states the intended use: the LLM or user maps a commercial model to an archetype using the returned metadata. It also explicitly notes that no server-side mapping occurs, which tells the agent not to expect the API to perform that task. It does not explicitly name sibling tools as alternatives, but the purpose is distinct enough that this is a minor gap.

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

plan_passageA

Read-onlyIdempotent

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.

    ## Waypoints must stay in the water

    This server does no land check. It samples wind and sea along the
    polyline you pass, then reports distance, ETA and complexity for that
    polyline, whatever it crosses. A leg drawn through a peninsula raises
    no error: it returns a passage that is too short, too fast, and scored
    on conditions the boat would never meet.

    So the route is yours to draw. Between every consecutive pair of
    waypoints the straight line must stay at sea. Add intermediate
    waypoints to round anything the direct line would cut: headlands,
    peninsulas, islands, shoals.

    - Toulon to Saint-Tropez: the direct line crosses the Massif des
      Maures. Pass south of the presqu'île de Giens, then round cap Bénat
      and cap Camarat before turning north into the gulf.
    - Brest to Douarnenez: the direct line crosses the presqu'île de
      Crozon. Exit the goulet, round the cap de la Chèvre, then head east
      into the bay.

    Keep about 1 NM of clearance off headlands, more with onshore wind or
    swell, and do not shave the inside of islands. Extra waypoints are
    close to free: the cap is 50, and sampling cost follows
    ``segment_length_nm`` and total distance, not the waypoint count. When
    in doubt, add the waypoint.

    A waypoint that lands ashore has a second effect. Open-Meteo returns
    no sea state over land, so those samples carry a null wave height and
    the complexity score silently falls back to wind only, dropping the
    axis that would have flagged a rough passage.

    Name the capes you routed around in your reply ("passage au large du
    cap Bénat"), so the user can correct a leg you drew wrong.

    ## 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.
    - ``disclaimer``: usage warning to relay (see below).

    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 …").
    - ``notices`` / ``meta_notices``: the same warnings as codes with
      their values (``{"code": "sweep.skipped_windows", "params": …}``),
      for a client that says them in another language. Read the French
      ``message`` and ignore these.
    - ``disclaimer``: usage warning to relay (see below).

    ## ALWAYS relay the disclaimer

    This tool returns an ETA and a difficulty score the user may act on to
    decide whether to put to sea. Carry the ``disclaimer`` field into your
    reply, once, in the user's language, phrased naturally rather than
    quoted verbatim. Put it after the numbers, not before: it qualifies
    them, it does not replace them. Do not drop it because the plan looks
    easy, and do not repeat it on every follow-up turn about the same
    passage.

    ## 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 to 50.
            Used exactly as drawn. Read "Waypoints must stay in the
            water" above before building it.
        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

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, and the description adds substantial non-obvious behavior on top: the server does no land check and silently returns over-short passages for legs crossing peninsulas, land waypoints cause null wave heights that degrade complexity to wind-only scoring, motor params are silently ignored unless paired, and the openwind_url must be used verbatim because it points at a configurable environment. These are exactly the surprising traits an agent needs to know.

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 well-structured with markdown headers, front-loaded routing decisions, bolded hard requirements, and concrete worked examples. It is, however, notably long, and the compare-windows mode is described twice (in 'Returned payload' and again in the standalone 'Compare-windows mode' section) with redundant payload details; the host-by-host rendering inventory is also more exhaustive than strictly necessary. Strong organization keeps this from dropping lower, but some sentences do not earn their 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?

Given the tool's high complexity — 13 parameters, two modes, safety-relevant routing constraints, an output schema, and UI integration — the description leaves nothing an agent needs to call it correctly undocumented: all parameters, both payload shapes, failure modes (ForecastHorizonError), result handling (disclaimer relay, openwind_url inclusion), and the critical no-land-check caveat. The presence of an output schema means return structures are partly covered by structured data, and the description still adds semantic meaning to those fields.

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 of parameter documentation — and it delivers. The Args section documents all 13 parameters with concrete defaults (efficiency 0.85/0.75/0.65/0.55), ranges (motor_speed_kn (0,10], min_upwind_twa_deg [25,70]), pairing constraints (motor_threshold_kn must be paired with motor_speed_kn), the model cascade ('auto' tries AROME→ICON-EU→ECMWF→GFS), and cross-references (archetype names via list_boat_archetypes, waypoint construction rules).

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 opening line states a specific verb and resource ('Plan an A→B passage') and immediately distinguishes the two operating modes (compare-windows default vs single departure). The routing section explicitly names sibling tools (get_marine_forecast, read_me) and states when plan_passage should NOT be called, so an agent can disambiguate without opening any schema.

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?

The 'Tool routing' section is a model of usage guidance: it classifies four question types, maps each to a tool or mode, gives concrete example phrasings in French and English, and closes with the rule of thumb ('if the user does NOT give an exact hour, prefer compare-windows'). When-not-to-use is explicit with exclusions for pure weather lookups and methodology questions.

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

read_meA

Read-onlyIdempotent

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

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds value by disclosing the output format (Markdown) and the specific methodology topics covered, which helps set agent expectations beyond the structured fields.

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 front-loaded with the core purpose, followed by clear usage guidance and a structured list of covered topics. Every sentence contributes useful information without 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?

Given the zero-parameter input and presence of an output schema, the description provides all necessary context: when to call, what it returns, and what content to expect. An agent can select and invoke this tool correctly without further clarification.

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 is empty, so there are no parameter semantics to clarify. The baseline of 4 applies because no parameter documentation burden exists.

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 states a specific verb and resource: 'Return OhMyWind's calculation methodology as Markdown.' It clearly distinguishes this tool from siblings like plan_passage and get_marine_forecast, which serve different purposes.

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 says 'Call this when the user asks how passage timing, complexity, or boat speed are computed' and provides concrete example queries. It does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateAug 7, 2026

Changedplan_passage1 field changed

addedInput schema / properties / min_upwind_twa_deg

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Min Upwind Twa Deg"
+}

4 tool updatesAug 2, 2026
- First observedget_marine_forecast
- First observedlist_boat_archetypes
- First observedplan_passage
- First observedread_me

Related MCP Connectors

Solano — marine & outdoor weather A
fr.solanometeo
Marine and outdoor weather: multi-model forecasts, official bulletins, tides, anchorages.
Weather Services Location Services Travel & Transportation
91
Nausika A
app.nausika
Mediterranean marine, nautical, sailing: forecasts, tides, sea routes, anchorages, POIs for AI.
Location Services Travel & Transportation Weather Services
192
SeamarkOAuth
app.seamark
Personal sailing voyage log: trips, legs, ships, crew and GPX tracks with honest statistics.
Travel & Transportation Location Services
1
Find My Tide A
com.findmytide
Tide times and heights for about 4,600 US and Canadian stations. Not for navigation.
Weather Services Location Services
31

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 7 months ago (2026-03-12 01:54 UTC)
2
-
Shipxy MCP Server
Location Services Travel & Transportation Weather Services
garrettXu
A
license
Not graded
quality
D
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 4 months ago (2026-06-11 09:47 UTC)
14
MIT
windscout-mcp
Weather Services Web Scraping
jwillert
A
license
A
quality
D
maintenance
MCP server for wind forecasts, live measurements, wave forecasts, and tides, enabling kite and surf spot checks via AI assistants.
Updated 3 months ago (2026-06-21 16:53 UTC)
5
5 npm
MIT
mcp-maritime
Weather Services Travel & Transportation
Ryo-Suzukii
A
license
Not graded
quality
D
maintenance
Provides real-time maritime weather data, tropical cyclone warnings, and route calculations for AI agents.
Updated 4 months ago (2026-06-11 00:15 UTC)
MIT