ocean-schedules

get_schedules

Published forward sailing schedules on an origin→destination lane: carrier, vessel, voyage, ETD/ETA, cut-offs and routing (leg count, transshipment ports, distance, CO2 per TEU and the port-by-port route_legs where the carrier publishes them; null where they do not), soonest first, from each carrier's own published schedules. Use this to find concrete upcoming departures to book. Every schedule time (published_departure, published_arrival, cut-offs, route_legs times, the from window) is the local time of its own port as the line publishes it, written without a timezone offset (2026-10-01T13:00:00): quote the digits and do not convert them; departure_precision/arrival_precision say minute (a time) or day (a date only); only retrieved_at is UTC and carries an offset; use transit_days for voyage length. The answer also carries carriers: one entry per line with carrier_code, carrier_name and count (its sailings in this answer; the counts add up to count), most first. An entry has error only when that line was asked live for this lane in this request and gave no answer: timeout (no answer in time), failed (error or unreachable), or paused (not asked; it timed out twice in a row here, retried after 6 h). A line that answered it has no sailings carries no error, and a line in error is listed even at count 0. With Navo Tokens this costs 80 tokens for a new port pair and 10 for a repeat of the same pair within 24 hours (shared with the other lane search); an empty answer is free.

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": {
      "origin": "<origin>",
      "destination": "<destination>"
    },
    "name": "get_schedules"
  }
}

Input Schema

Name	Required	Description
`from`	No	Earliest departure date as YYYY-MM-DD, with no time and no timezone offset. Must be today or later. Sailings are returned from 00:00 of that date, read in each port's local time, onward. Omit for today.
`origin`	Yes	Origin port UN/LOCODE, e.g. CNSHA
`destination`	Yes	Destination port UN/LOCODE, e.g. NLRTM

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / from

Added value: +{
+  "description": "Earliest departure date as YYYY-MM-DD, with no time and no timezone offset. Must be today or later. Sailings are returned from 00:00 of that date, read in each port's local time, onward. Omit for today.",
+  "type": "string"
+}

First observedJun 25, 2026

TDQS

A4.1/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 does so richly: it explains timezone handling, precision semantics, carrier error states, token costs, and the shape of the response. These are meaningful behavioral details an agent needs before invoking the tool.

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?

The description is front-loaded with the core purpose and the extra length is largely justified by the absence of an output schema. Some sentences are dense and semicolon-heavy, but the detail is relevant and not redundant.

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 complexity, lack of annotations, and lack of an output schema, the description is complete enough: it covers returned fields, ordering, carrier entries, error conditions, time semantics, and cost. Result limits or pagination are not mentioned, but they are not essential for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces the local-time semantics of the 'from' window, but adds no syntax or usage details beyond what the schema provides.

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?

The description clearly states a specific resource and scope: published forward sailing schedules on an origin→destination lane, including the exact returned fields. It does not explicitly differentiate itself from the sibling tool find_best_sailings, so it falls short of the top score despite being otherwise precise.

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?

It gives a clear use case: 'Use this to find concrete upcoming departures to book.' However, it does not name alternatives such as find_best_sailings or compare_lanes, nor does it state when not to use this tool.

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

All ocean-schedules 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.