Skip to main content
Glama

Canal Nav

by com.canalnav

Plan a round trip

plan_round_trip

Plan return-to-start cruises from a point on the inland waterways of Great Britain, sized to fit a number of days. Returns several options: circular loops where the canal network offers one (canal "rings"), plus out-and-back and fewest-locks alternatives, each with distance, lock count, day-by-day plan and suggested overnight moorings. Timing is lock-aware and closures from every GB navigation authority are flagged on each option. Give boat dimensions to get fit warnings, and routes touching tidal water carry a tidal safety warning. The start can be a place name or "lat,lon" coordinates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoStart date (YYYY-MM-DD) for closure checking. Defaults to today.
daysYesNumber of days the round trip should fit in.
startYesStart (and finish) point: a place name on the waterways 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.
boat_air_draughtNoBoat air draught (height above the waterline, for bridges and tunnels). Metres or feet/inches.
cruising_hours_per_dayNoCruising hours per day. Default 6.

TDQS

A4.7/5.0
Behavior5/5

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

No annotations are provided, so the description carries full burden. It goes beyond a basic summary by disclosing output variety (rings, out-and-back, fewest-locks), detailed output attributes (distance, lock count, day-by-day plan, moorings), and safety/timing behaviors (lock-aware timing, closures flagged, fit warnings, tidal warnings). This is rich behavioral context.

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 four sentences, each contributing unique information. It is front-loaded with the core purpose, then details options, safety aspects, and input flexibility. No redundancy or fluff.

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 complexity (9 parameters, no output schema), the description provides thorough contextual completeness. It explains the key return values (options, distances, plans, warnings) and covers safety considerations. The only omission is error handling, but that is not essential for tool selection and 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?

Schema coverage is 100%, so all 9 parameters are already described. The description adds value by explaining that boat dimensions trigger fit warnings and that lock-aware timing relates to lock_minutes, which enhances understanding of the parameters' purpose. Baseline 3 raised to 4 for this added context.

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 clearly states the tool's purpose: planning return-to-start cruises on GB inland waterways, sized by days. It distinguishes itself from siblings by explicitly mentioning circular loops (rings), out-and-back, and fewest-locks alternatives, which are unique to round-trip planning. The verb 'plan' and resource 'round trips' are specific.

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 implicitly differentiates this tool from plan_route by focusing on round trips, indicating when to use it. However, it does not explicitly say 'use this instead of plan_route when you need a return-to-start trip' or provide exclusions. The context is clear but not explicit about alternatives.

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