Gillby

Plan a route for a confirmed vessel

plan_route

Read-onlyIdempotent

Requires a free Gillby account (OAuth sign-in). Chart-aware water routing between from/to spot IDs or lat,lon. Supply a confirmed library boat ID or measured draft, with beam, airDraft, ukc, bridgeMargin and speed overrides in feet/knots. Checks chart depths and tides along the geometry, samples across supplied beam, identifies bridges and restrictions, checks predicted MHW bridge clearance when data permits, and adds route weather samples. Does not infer saved vessel settings. Supports ordered via stops and a hard corridor=icw constraint. Cold charts may take 110 seconds. Interpretation: omit boat unless the user supplied or confirmed it. Describe lightning as flashes observed or not detected in the stated window, never a clear/safe guarantee. Report unavailable/QC-failed sources even when freshness.stale=false; fresh does not mean every source is usable. Model sea height is not breaking surf height. Tide heights at different local MLLW gauges do not establish relative channel depths. High tide is not necessarily slack current. For kitesurfing use get_conditions with kiteStyle (freeride/waves/foil), kiteExperience and rider-supplied kiteMinWindKt/kiteMaxWindKt. Read kiteboarding for weather screening, gust spread and explicitly unverified launch status. Never infer the rider wind range, legal launch access or rescue coverage. Activity keys: kite, surf, skim (flatland), skim-wave (wave riding), paddle (flatwater paddleboard), sup-surf (SUP surf). Skim suitability is unscored without shoreline observations; missing scores must not inherit another activity. Offshore wind can favor surf while increasing paddleboard drift risk. A point depth cannot prove route clearance. Do not invent detection percentages, future readings, vessel ownership, or app settings instructions. Units: ft, kt, s, F, mi; directions FROM. Returns data and source/freshness metadata.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "plan_route"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well past the safe-read annotations: names the OAuth account prerequisite, discloses that cold charts may take 110 seconds, states that saved vessel settings are never inferred, lists the checks performed (chart depths, tides, bridge clearance, weather samples), and notes that data plus source/freshness metadata is returned. That is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Badly front-loaded – the first sentence is an account requirement rather than the purpose – and roughly half the text is an 'Interpretation:' block about lightning, kitesurfing, skim/SUP activity keys and tide-gauge reasoning that has almost nothing to do with planning a route. Structured labels help, but the off-topic bulk is a significant conciseness failure.

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?

With no output schema, the description still states what comes back ('data and source/freshness metadata') and warns that fresh does not imply every source is usable, plus auth and latency caveats. Only the detailed response shape is left unspecified, which is acceptable for a nested-query routing tool.

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 effectively 0% at the top level, so the description carries the burden and does: it explains that from/to accept spot IDs or lat,lon, that boat and draft are alternative vessel definitions ('or measured draft'), which fields are overrides, the units (ft/kt), ordered via stops, and the hard corridor=icw constraint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource – chart-aware water routing between from/to spot IDs or lat,lon – and the title scopes it to a 'confirmed vessel', which implicitly separates it from plan_my_route. It does not explicitly name plan_my_route or check_route_conditions, so the boundary between siblings must be inferred from 'Does not infer saved vessel settings'.

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?

Gives real usage rules ('omit boat unless the user supplied or confirmed it', kitesurfing goes to get_conditions with kiteStyle), but none of these route the agent between plan_route, plan_my_route, and check_route_conditions. The when-not condition for this tool is only implied.

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

All Gillby tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.