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 with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 04:39
Transport: Streamable HTTP
URL
Repository: qdonnars/ohmywind
GitHub Stars: 10
Server Listing: OhMyWind

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 …").
    - ``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?

Discloses critical behavioral traits well beyond the readOnlyHint/openWorldHint/idempotentHint annotations: the server does no land check and silently returns an under-scored passage for a leg through a peninsula; waypoints on land yield null wave heights that silently drop the sea axis from the complexity score; motor_threshold_kn is ignored unless paired with motor_speed_kn; and the ForecastHorizonError failure mode is named. The annotations are consistent with the described computation-only behavior — no contradiction.

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?

Exceptionally well-structured: front-loaded routing section, clear headings, numbered lists, and concrete geographic examples (Toulon→Saint-Tropez, Brest→Douarnenez) with zero filler. Loses a point for redundancy — the multi-window payload is described in three places (the Returned payload section, the compare-windows subsection under Args, and the dedicated Compare-windows mode section). For a tool this complex, the overall length is justified.

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 13-param, two-mode tool with 0% schema coverage and three siblings, nothing an agent needs is missing: routing rules, waypoint geometry safety with named capes, every parameter's semantics, both return payload shapes, failure modes, the mandatory disclaimer relay rule, the hard openwind_url requirement, and host-specific rendering behavior. The existing output schema covers the structured-return burden; the description covers everything else.

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?

With 0% schema description coverage, the description carries the full burden, and the Args section delivers richly: ISO-8601 timezone-aware format for departure, the AROME→ICON-EU→ECMWF→GFS fallback chain for model, efficiency values mapped to boat states, the behavioral switch of latest_departure into multi_window mode, target_eta's ±2h filter, pairwise motor-parameter constraint, numeric ranges, and defaults. This far exceeds the bare schema titles.

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?

States a specific verb+resource ('Plan an A→B passage') and immediately differentiates the two operating modes (compare-windows vs single departure). The tool-routing section names each sibling with the exact condition that selects it ('Pure weather lookup... call get_marine_forecast', 'Methodology question... call read_me'), so the agent can distinguish this tool without opening any sibling 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: read this first' section is explicit and exhaustive: four numbered scenarios mapping user question types to tool+mode, including a negative rule ('Do NOT call plan_passage: there's no route to plan') and a decision rule of thumb ('if the user does NOT give an exact hour, prefer compare-windows'). This is the gold standard for when-to-use guidance.

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. Dates show when Glama detected each change.

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

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

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

Related MCP Connectors

Nausika A
app.nausika
Mediterranean marine, nautical, sailing: forecasts, tides, sea routes, anchorages, POIs for AI.
Location Services Travel & Transportation Weather Services
192
sailing A
com.whensport
First dedicated sailing MCP — America's Cup, SailGP, Vendée Globe. Events, venues, teams, schedule.
Sports
2
Canal Nav A
com.canalnav
Plan canal routes on Great Britain's waterways: lock-aware timing, live closures, boat-fit checks.
Travel & Transportation Location Services
61
noaa-marine-mcp-server A
io.github.cyanheads
Find NOAA tide stations and NDBC buoys, fetch tide predictions, currents, and live conditions.
Weather Services Government Data Location Services
721

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 6 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 3 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 3 months ago (2026-06-21 16:53 UTC)
5
13
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 3 months ago (2026-06-11 00:15 UTC)
MIT

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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources