Skip to main content
Glama

Ferryhopper

by com.ferryhopper.mcp
OverviewDiscussionsAdmin

Search Ferry Trips

search_ferry_trips
Read-only

Search ferry trips as an ordered chain of 1 to 5 legs. Takes human-readable location names (e.g. city or port name) for each leg, not port codes — no need to call get_ports first. Availability flags (cabin, vehicles, pets, e-ticket) are reported per segment.

  • One leg: a plain one-way search.

  • Two legs where leg 2 reverses leg 1 (e.g. leg 1 Piraeus→Mykonos, leg 2 Mykonos→Piraeus): a round trip.

  • Up to 5 legs otherwise (e.g. A to B, then B to C, then C to D): an island-hopping chain.

Legs after the first must depart from the location the previous leg arrived at, and must be in chronological order (a later leg may share the same date as an earlier one, but may not precede it).

The response returns each leg's available options independently (legs[].options) — options are never filtered against another leg's options. Consecutive legs must leave enough time between one leg's arrival and the next leg's departure to be a valid connection; this is not pre-filtered server-side or reflected in this output, so do not assume every combination of options across legs is a valid connection — the widget the user interacts with enforces this.

Input Schema

NameRequiredDescriptionDefault
legsYesAn ordered chain of sailing legs. A one-way search is a single leg. A round trip is 2 legs where leg 2 reverses leg 1 (e.g. leg 1 Piraeus→Mykonos, leg 2 Mykonos→Piraeus). An island-hopping chain is up to 5 legs, e.g. A→B, then B→C, then C→D. Each leg after the first must depart from the location the previous leg arrived at.

Output Schema

NameRequiredDescriptionDefault
legsYesOne entry per requested leg, in chronological order. For a one-way search this has 1 entry. For a round trip (2 legs where leg 2 reverses leg 1) index 0 is outbound and index 1 is the return. For a longer island-hopping chain there are 2-5 entries, one per leg.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / legs / items / additionalProperties
      Removed value: -false
    • addedInput schema / properties / legs / items / properties / departureDate / pattern
      Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / properties / legs / items / properties / options / items / properties / segments / items / properties / arrivalDateTime / pattern
      Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"
    • addedOutput schema / properties / legs / items / properties / options / items / properties / segments / items / properties / departureDateTime / pattern
      Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, yet the description still adds real behavioral context: availability flags are reported per segment, options are returned per leg and never cross-filtered, and connection feasibility is NOT validated server-side. That last point is a genuine gotcha disclosure an agent could not infer from the schema. No return format or pagination detail is given, but an output schema exists.

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?

Front-loaded with the core definition, then a compact bullet list for the three query shapes, then constraints, then the caveat about connection validity — a sensible ordering. Slightly redundant: the round-trip reversal example is repeated in the array schema description, costing a little space.

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 single-parameter, read-only search with an output schema present, the description covers input shape, leg-chaining rules, output structure at a high level, and the one non-obvious limitation (connections not pre-validated). Nothing an agent needs to call this correctly is missing.

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, but the description adds meaning the schema does not fully carry: location values are human-readable names or search terms rather than port codes, and consecutive legs must leave a real connection buffer. Those are semantic constraints on how to populate the single `legs` parameter, not restatements.

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?

Opens with a specific verb+resource and a precise scope: 'Search ferry trips as an ordered chain of 1 to 5 legs'. The leg-chain framing (round trip = reversed leg 2, island-hopping = up to 5 legs) distinguishes it from a flat search, though it never names sibling search_trips or get_direct_connections_for_ports explicitly, so the differentiation is inferential.

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?

It lays out exactly which shapes of query this tool handles (one-way, round trip, multi-leg chain) and explicitly rules out an alternative: 'no need to call get_ports first'. It also states the hard preconditions — legs must chain end-to-start and be in chronological order — so the agent knows when a query is invalid before calling.

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

All Ferryhopper toolsInspect
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.

Resources