Ferryhopper

Ferryhopper MCP is a durable, attributable remote MCP server operated by Ferryhopper. The official product site at https://ferryhopper.com presents Ferryhopper as a platform for discovering and booking ferry travel. The provider's technical documentation at https://partners.ferryhopper.com/mcp explicitly names Ferryhopper's Model Context Protocol and addresses developers building LLM and travel-agent applications. Smithery lists the verified identifier ferryhopper, marks it as remote and deployed, and publishes the direct deployment endpoint https://ferryhopper.run.tools. That endpoint carries the Ferryhopper identity in its hostname and is mapped to an independently useful Ferryhopper MCP offering by the provider documentation and published product communication. The provider-hosted technical overview at https://ferryhopper.github.io/fh-mcp/ adds a public description of the tools and booking handoff. There is no verified public Ferryhopper source repository for this service, so repo_url remains empty rather than misrepresenting a third-party source as official code.

Purpose and operation

According to the provider, the service connects an MCP-capable AI client to ferry data for travel planning. The get_ports tool returns port information. get_direct_connections_for_ports supports finding direct connections between ports. search_trips searches available ferry trips for a route and date. The documentation describes ferry connections across many countries and operators together with current travel information and indicative prices. These details are time-sensitive and should be treated in conversation as provider results with a retrieval time. A model must not add availability, disruption claims, fare conditions, or connections that Ferryhopper did not return. Multi-leg travel can be proposed, but the traveler remains responsible for the final selection.

The service is suitable for a catalog as an independent remote MCP distribution point because the product page, technical documentation, Smithery deployment, and provider communication identify the same operator and a durable capability. An anonymous successful connection is not required for that assessment. The endpoint returns 401 without an Authorization header, which demonstrates an authentication boundary rather than disproving its existence. Before production use, the client and operator must verify current authentication, transport requirements, tool schemas, and usage terms with the provider. OAuth or other headers must be taken only from current official sources.

Authorization, privacy, and booking boundaries

Searching ports and trips normally requires fewer permissions than a later booking handoff. The official page describes a direct link to Ferryhopper for booking and payment. The MCP client should therefore display only a provider-supplied handoff and must obtain clear consent before transferring personal travel or contact data. User permissions should be limited by role, purpose, and session. Itineraries, travel dates, names, ages, contact details, or accessibility needs may be personal information. They should be minimized, purpose-bound, and transmitted only with verified authorization. Operators must review the privacy basis, retention, logging, subprocessors, regions, and deletion process. A local MCP client does not automatically prevent requests from reaching the remote service or results from reaching an attached cloud model.

The search is mostly read access. A booking link can nevertheless lead to an external write and payment flow. Booking, payment, or other write access must never be inferred from a search request. The user must review route, date, travelers, operator, terms, total, and refund rules in the official checkout and explicitly confirm. Card data, bank details, credentials, booking references, and payment tokens do not belong in this catalog and should be handled only in the provider-controlled payment area. The MCP server is not an independent payment review and does not guarantee availability or contract performance.

Security boundaries and suitable use

Remote tool responses, port names, travel notices, and operator free text are untrusted input. Prompt injection in this data must not trigger a new permission, contact-data transfer, booking, or payment. Clients should allowlist the endpoint, enforce TLS, use least privilege, minimize data before sending, require confirmation for external handoffs, and apply safe limits to errors, timeouts, and retries. The service suits research, route comparison, travel planning, and a deliberately confirmed booking handoff. It is not suitable for hidden bookings, automatic payments, arbitrary writes, or dangerous local commands. The E-E-A-T basis of this entry is, according to the provider, the Ferryhopper product site, Ferryhopper documentation, the published MCP overview, and Smithery deployment data. These sources support attribution but do not constitute a security certification. Re-verify the endpoint, authorization, and privacy terms with the provider before every production integration.

An MCP client with remote HTTP support, network access to the Ferryhopper endpoint, and current authorization documented by the provider. Personal travel or booking data requires consent, role checks, and secure local handling.

Configure the official remote endpoint https://ferryhopper.run.tools in the MCP client using current Ferryhopper or Smithery documentation. Verify identity, transport, tool schemas, authorization, and confirmation boundaries before use.

https://ferryhopper.run.tools

The endpoint requires authorization when no Authorization header is supplied. Verify current OAuth or header requirements only in official Ferryhopper documentation. Store no credentials, tokens, or keys in the catalog.

Read access to ports, direct connections, and available trips; the booking link can lead to external write and payment operations. User confirmation, role checks, and least privilege are required.

Route, date, and search data are sent to the remote service; personal travel and contact data should be shared with the provider or checkout only when minimized, authorized, and purpose-bound.

Prompt injection in travel or operator data, endpoint confusion, PII in logs, unconfirmed booking handoffs, and cloud-model sharing. Mitigate with allowlisting, TLS, DLP, auditing, and confirmations.