Skip to main content
Glama

Canal Nav

by com.canalnav

Plan a canal route

plan_route

Plan a boat journey between two points on the inland waterways of Great Britain (canals and navigable rivers). The route follows the water itself, not roads. It counts every lock and estimates cruising time from realistic boat speed plus time per lock. Live closures and stoppages from every GB navigation authority (Canal & River Trust, Environment Agency, Scottish Canals, Broads Authority and others) are routed around automatically, and when a dated closure blocks the natural line the result compares waiting for it to reopen against taking the detour. Give boat dimensions to get per-waterway fit warnings (too long, too wide, too deep, too tall for a waterway on the route). Routes that cross tidal water carry a tidal safety warning. Places can be names (resolved on the waterway network) or "lat,lon" coordinates. If a name matches several distinct locations the tool returns the candidates instead of guessing; call again with the chosen one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesDestination: a place name or "lat,lon" coordinates.
dateNoDeparture date (YYYY-MM-DD) for closure checking. Defaults to today.
fromYesStart point: a place name on the waterways (e.g. "Braunston Marina") or "lat,lon" coordinates.
boat_beamNoBoat beam (width). Metres by default (e.g. 2.08), or feet/inches (e.g. "6'10\"").
boat_lengthNoBoat length. Metres by default (e.g. 17.4), or a feet/inches string (e.g. "57ft").
boat_draughtNoBoat draught (depth below the waterline). Metres or feet/inches.
lock_minutesNoMinutes to work through one lock. Default 15. Experienced crews may use 10, single-handers 20 or more.
boat_air_draughtNoBoat air draught (height above the waterline, for bridges and tunnels). Metres or feet/inches.
cruising_hours_per_dayNoCruising hours per day, used to split the journey into days with suggested overnight moorings. Default 6.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and fully delivers. It discloses that routes follow water not roads, counts locks, estimates time, automatically routes around closures, compares waiting vs. detour, gives per-waterway fit warnings, includes tidal safety warnings, and returns candidates on ambiguous names. This is rich behavioral disclosure.

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 long but every sentence earns its place. It is front-loaded with the primary purpose, then systematically covers routing behavior, closures, boat limits, tidal warnings, and input formats. No fluff or repetition; the structure is logical and dense.

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 (9 parameters, no output schema), the description is comprehensive. It explains core behavior, closure handling, detour comparison, fit warnings, tidal warnings, and input ambiguity. It doesn't explicitly describe the response format (e.g., list of waypoints, but it mentions 'returns the candidates' and 'the result compares waiting'), so a 4 is appropriate rather than a 5.

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?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond schema by explaining why boat dimensions matter ('Give boat dimensions to get per-waterway fit warnings') and how place names or coordinates are interpreted, including the ambiguity behavior. These insights complement the schema's field-level descriptions.

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 clear, specific verb and resource: 'Plan a boat journey between two points on the inland waterways of Great Britain.' It distinguishes itself from siblings by focusing on journey planning, while siblings like 'find_place' or 'get_closures' serve different purposes. The scope (canals and navigable rivers) is explicit.

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 (planning a boat journey, with lock counting, closures, boat-dimension checks, and tidal warnings). However, it doesn't explicitly mention alternatives or exclusions (e.g., when to use will_my_boat_fit instead), so it stops short of a 5. The guidance is implicit in the feature list.

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

All Canal Nav toolsInspect
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.4/5.0
Disambiguation5/5

Each tool targets a distinct aspect of canal navigation: place lookup, closures, route planning, round trip planning, business directory, and boat fit checks. There is no overlap in purpose, so an agent can reliably select the right tool.

Naming Consistency4/5

Most tools follow a verb_noun pattern (find_place, get_closures, plan_route, plan_round_trip, search_directory). 'will_my_boat_fit' is a question-phrase rather than a standard verb_noun, but it is still clear and stylistically consistent (lowercase with underscores).

Tool Count5/5

Six tools is well within the ideal range for a focused domain. Each tool is non-trivial and earns its place; there are no redundant or filler tools.

Completeness5/5

The tool set covers the full lifecycle of planning a canal trip: locating places, checking closures, planning both one-way and round trips, validating boat dimensions, and finding waterside services. There are no obvious dead ends or missing core operations.

Resources