OhMyWind

OhMyWind ⛵

Talk to your LLM. Cast off with confidence.

OhMyWind turns any MCP-capable assistant (Claude, Le Chat, Cursor, Goose, Zed, Continue) into a sailing planner. Ask in plain language, anywhere in the world: get a per-leg ETA, a 1‑5 complexity score, and a deep-link to the full plan. On the French Atlantic coast it goes further, swapping the global current model for the SHOM Atlas C2D and MARC PREVIMER atlases. Free, keyless, open source.

[CI]

ohmywind.fr · MCP endpoint · Changelog · AGPL-3.0 + trademark

[!WARNING] Decision-support tool, not a navigation instrument. OhMyWind does not replace the official marine forecast from your national weather service, up-to-date charts, or the skipper's judgement. Forecast models are sometimes wrong: you remain responsible for your passage.

[OhMyWind passage plan rendered in the web app]

Try it in 30 seconds

Claude: add it from the connector directory, in one click. Any other MCP client:

1. Open your MCP client and add the endpoint:

https://mcp.ohmywind.fr/mcp

2. Ask, in your own words:

"Demain matin, Marseille → Porquerolles, sur un Sun Odyssey 36. Bonne idée ? Combien de temps et c'est tendu comment ?"

3. Your assistant calls the OhMyWind tools and answers in plain language. On hosts that support the MCP Apps spec (Claude, Claude Desktop, ChatGPT, VS Code Copilot, Goose, Postman, MCPJam) you also get a live, interactive widget: the ohmywind.fr plan view rendered inline. On hosts that don't (Cursor, Le Chat, terminal), the assistant hands you the same plan as an ohmywind.fr deep-link. No account. No API key. No credit card.

First time with MCP? It takes 2 minutes. Pick your client on modelcontextprotocol.io/clients, then follow the remote-server quickstart. Claude Desktop users can start with the user quickstart. In Le Chat, add it under Connectors → Add connector → Custom MCP connector and paste the endpoint above.

If your client only speaks stdio

Some hosts cannot reach a remote MCP server directly yet. Bridge it with mcp-remote, which runs locally and forwards to the endpoint:

{  "mcpServers": {    "ohmywind": {      "command": "npx",      "args": ["-y", "mcp-remote", "https://mcp.ohmywind.fr/mcp"]    }  }}

Nothing else to configure: no account, no API key, no OAuth, no credit card. A client that asks you for credentials is guessing rather than reading the server, and you can leave those fields empty.

Ask it something real

Three prompts, each exercising a different tool:

• "Quels bateaux tu connais ? J'ai un First 27." maps your boat to a polar archetype. The assistant chooses from the descriptions; there is no server-side lookup table.
• "Le vent au cap Sicié samedi après-midi ?" returns wind and sea at one point, AROME first, in knots.
• "Meilleur créneau cette semaine pour Marseille → Porquerolles ?" walks every hourly departure up to 14 days out and compares them in one call.

Why OhMyWind

What the LLM sees

Four MCP tools, all async, all keyless:

plan_passage declares an MCP Apps UI resource (ui://openwind/plan-passage) on its _meta. Hosts that support MCP Apps render the live ohmywind.fr/plan?… view in a sandboxed iframe automatically, with no host-specific CSS and no vendor lock-in. Hosts without MCP Apps support silently get the structured payload + the openwind_url deep-link.

Architecture

packages/├── data-adapters/   # pure domain logic (forecast adapters, polars, routing, complexity)├── api/             # REST API as a Starlette app: create_app(settings, mcp_app=None)├── mcp-core/        # FastMCP server (cloud-agnostic, no Gradio, no HF deps)├── hf-space/        # Docker wrapper for Hugging Face Spaces (~100 lines + Dockerfile)└── web/             # React 19 + Vite app deployed to Cloudflare Pages (ohmywind.fr)

api and mcp-core both stay deployment-agnostic, and neither depends on the other: the API serves without an MCP server behind it, and the MCP tools run over stdio with no HTTP at all. Re-deploying on Fly, Modal, or a VPS is a different Dockerfile and an entry point that calls create_app() and build_server(). See docs/architecture.md.

Run locally

# Tests + lint (data-adapters & mcp-core, Python via uv)cd packages/mcp-coreuv sync --all-extrasuv run pytest -x -quv run ruff check .
# Local HTTP MCP smokecd packages/hf-spaceuv run python app.py   # serves :7860, point any MCP client at /mcp
# Web app (ohmywind.fr)cd packages/webnpm installnpm run dev            # vite dev servernpm run build          # outputs packages/web/dist

V1 scope

Wind, sea (Hs max), per-leg ETA, 1–5 complexity. Tides and currents ignored on the Med (negligible). No automatic routing optimisation: the LLM and the human stay in the loop. Roadmap and scope decisions live in a plan/ directory kept local to the working copy, not published here.

Calculation method

Defaults below are what the MCP server uses unless overridden by tool parameters. Implementation: packages/data-adapters/src/openwind_data/routing/passage.py.

Polar speed model

• 8 archetypes (cruiser_20ft, cruiser_25ft, cruiser_30ft, cruiser_40ft, cruiser_50ft, racer_cruiser, catamaran_40ft, voile_aviron_16ft), each with an ORC-style polar in packages/data-adapters/src/openwind_data/routing/polars/.
• Lookup is bilinear interpolation in (TWS, TWA), clamped at grid edges.
• TWA is symmetric [0°, 180°] only, no port/starboard distinction.

Boat speed adjustments

• Efficiency factor (default 0.75). ORC polars are theoretical maxima. Real cruising loses ~25% (sail trim, comfort margins, helmsman, untracked currents). Override per call: 0.85 racing, 0.75 cruising, 0.65 loaded family cruising, 0.55 heavy seas / fouled hull.
• VMG / tacking correction. When the route's TWA is below the boat's optimal upwind angle (typically ~42-48°), the simulator assumes the sailor tacks. Effective speed toward destination is polar(optimal_TWA) × cos(optimal_TWA − route_TWA). At dead upwind this reduces to polar(opt) × cos(opt) ≈ polar / √2; at TWA=20° with opt=45° the reduction is only cos(25°) ≈ 0.91.
• Wave derate (opt-in). max(0.5, 1 − 0.05 × Hs^1.75 × cos²(TWA/2)). Disabled by default; sea state feeds the warning bar rather than slowing the boat.
• Minimum boat speed. 0.5 kn floor, prevents division blow-up in extreme stalls.

Timing

• Single-pass approximation. A 6 kn heuristic estimates segment mid-times, then real polar speeds are computed at each mid-time's actual wind. No convergence iteration. Bias is bounded by the Mediterranean's multi-hour wind correlation length.
• Routes are split into ~10 nm sub-segments by default for per-segment weather sampling. Drop to 5 nm for tight coastal work; raise to 20 nm for long offshore legs.

Compare-windows mode

plan_passage accepts an optional latest_departure that turns the call into a window comparison: it walks N hourly departures over the same route and returns one entry per window. Weather is fetched once (cache prewarm), simulations are in-memory. Hard cap: 14 d × 24 h = 336 windows. The LLM (not the server) picks the best option qualitatively.

Currents: why SHOM and MARC, not just the global model

Open-Meteo's SMOC current field is global and 8 km wide. On the French Atlantic coast that is not enough: the passes where a current decides the passage are narrower than one grid cell. The adapter therefore stacks two coastal sources on top of it, the SHOM Atlas C2D and the MARC PREVIMER atlases, and falls back to SMOC outside their coverage.

The gap is measured, not assumed. Over 120 SHOM-covered points and 24 hourly snapshots each (2880 pairs, seed 42), pairwise speed disagreement in knots:

Read the first row against the second. The MARC harmonic engine tracks the SHOM atlas about twice as closely as the global model does, and direction tells the same story (7.3° median between SHOM and MARC, 23.6° between SHOM and SMOC). A p95 spread of 1.6 kn against a 5 kn boat is the difference between carrying a pass and fighting it. Note what this is not: SMOC adds wind-driven and Stokes components that SHOM's harmonic atlas leaves out, so the second row mixes predictor skill with a genuine physical difference and is not a pure error metric. The third row is the one that decided the 5 GB payload was worth shipping.

Which of the two coastal sources wins where is measured too. SHOM C2D is not a set of measurements: per its own notice it is the output of 1988 to 2002 tidal models, depth-averaged and resampled on a lattice whose pitch is under a kilometre only in a few insets (Golfe du Morbihan, Rade de Brest, Sein, north Brittany) and 1.3 to 20 km elsewhere. A second bench (September 2026, 750 shelf points by distance to the nearest SHOM point, 16 named passes, 1,500 random points) found the two sources agree offshore whatever that distance, that MARC matches the HF-radar maxima in the Fromveur where SHOM's 1994 file does not, and that SHOM keeps an edge only in its fine insets. The cascade therefore takes SHOM only when a C2D point lies within 500 m, MARC next, SMOC last.

Full reports, per-atlas breakdown and method: docs/bench/currents_3way_2026-05-10_1818.md and docs/bench/currents_resolution_2026-09-12_1347.md.

Mediterranean defaults

• Tides ignored. < 40 cm in the Med, negligible vs. forecast uncertainty.
• Currents ignored. Liguro-Provençal current too weak / variable for V1.
• Wind model. AROME 1.3 km (≤48 h horizon, captures thermals and local winds). Auto-falls back to ICON-EU (≤5 d) → ECMWF IFS 0.25° (≤10 d) → GFS (≤16 d) when the passage extends past AROME.
• Wave model. Open-Meteo Marine (significant Hs, period, direction).

What's not modelled (V1)

• No automatic routing optimisation: the LLM and human stay in the loop on departure choice.
• No coastal acceleration zones (capes, peninsulas): the caller adds intermediate waypoints.
• No port/starboard polar asymmetry, no spinnaker-specific curves, no hull condition modelling beyond the efficiency knob.

Credits

Tidal currents on the French Atlantic coast: SHOM Atlas C2D and MARC PREVIMER (Ifremer). The prebuilt atlases live in a private HF dataset, and stay private: the raw MARC NetCDF is used under a no-redistribution commitment, so the Space pulls them with a read token rather than shipping them here. Building without that token is supported and falls back to the global current model.

Wind & sea: Open-Meteo (CC BY 4.0). Hosting: Hugging Face Spaces. Map tiles on ohmywind.fr: CARTO / OpenStreetMap.

License and trademark

Code: AGPL-3.0-or-later. That covers everything under packages/, the web app, the MCP server and the data adapters alike. Forking and redistribution stay free; if you serve a modified instance over the network (your own MCP endpoint, a derived web app), you must publish its source. Versions up to commit f276c3c were MIT-licensed and remain so: see COPYING.MIT.

Two things the AGPL licence does not cover:

• The name "OhMyWind", filed as a trademark at the INPI, the French industrial property office.
• The visual identity (logo, app icons), which stays under copyright.

Forks are welcome. Publish them under your own name and your own icons. The full policy, and what counts as a technical figure rather than brand identity, is in TRADEMARK.md.

Data is licensed separately by each provider: Open-Meteo forecasts under CC BY 4.0, SHOM Atlas C2D under Licence Ouverte Etalab 2.0, MARC PREVIMER under a no-redistribution commitment on the raw NetCDF. The per-source table lives in docs/methodologie.md.