VesselAPI MCP Server

Overview Schema Source Related Servers Discussions Admin

get_port_inbound

Retrieve vessels inbound to a port by matching reported destination and declared ETA within an arrival window; ETAs are vessel-reported, not predicted.

Instructions

Get vessels whose own reported destination is this port, with a declared ETA inside the arrival window. ETAs are reported by the vessels, not predicted.

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": {
      "unlocode": "<unlocode>"
    },
    "name": "get_port_inbound"
  }
}

Input Schema

Name	Required	Description
`etaTo`	No	End of ETA arrival window (RFC3339). Omit to default to 72 hours ahead.
`limit`	No	Results per page, 1 to 50. Defaults to 20.
`timeTo`	No	Only use reports received before this time, RFC3339. Defaults to now.
`etaFrom`	No	Start of ETA arrival window (RFC3339). Omit to default to now.
`timeFrom`	No	Only use reports received after this time, RFC3339. Defaults to 24 hours ago.
`unlocode`	Yes	UN/LOCODE of the destination port (e.g. NLRTM for Rotterdam)
`nextToken`	No	Pagination token from previous response

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.2.0Oct 30, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / timeFrom / description

Previous value: -"AIS position time range start (RFC3339 format)"New value: +"Only use reports received after this time, RFC3339. Defaults to 24 hours ago."

changedInput schema / properties / timeTo / description

Previous value: -"AIS position time range end (RFC3339 format)"New value: +"Only use reports received before this time, RFC3339. Defaults to now."

Changed7 schema fields changedv2.0.0Aug 20, 2026

changedInput schema / properties / etaFrom / description

Previous value: -"Start of ETA arrival window (RFC3339 format, e.g. 2026-03-07T00:00:00Z)"New value: +"Start of ETA arrival window (RFC3339). Omit to default to now."

changedInput schema / properties / etaTo / description

Previous value: -"End of ETA arrival window (RFC3339 format, e.g. 2026-03-14T00:00:00Z)"New value: +"End of ETA arrival window (RFC3339). Omit to default to 72 hours ahead."

changedInput schema / properties / limit / description

Previous value: -"Max results per page"New value: +"Results per page, 1 to 50. Defaults to 20."

addedInput schema / properties / limit / maximum
```
Added value: +50
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

changedInput schema / properties / limit / type

Previous value: -"number"New value: +"integer"

changedInput schema / required

Previous value: -[
-  "unlocode",
-  "etaFrom",
-  "etaTo"
-]New value: +[
+  "unlocode"
+]

Addedv1.3.0May 6, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden. It does add genuinely useful provenance context — ETAs are self-reported by vessels rather than predicted, which warns the agent about data reliability. However it says nothing about pagination behavior, result ordering, coverage gaps, or rate limits for a 7-parameter list tool.

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?

Two sentences, no filler, and the core selection rule is front-loaded before the data-provenance caveat. Every clause earns its place.

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?

For a 7-parameter tool with no output schema and no annotations, the description covers the essential semantic distinction (reported vs predicted ETA) and the windowing concept. It stops short of describing what a result record contains or how the two time axes interact, which would matter for an agent assembling a query.

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 every parameter including the etaFrom/etaTo window and timeFrom/timeTo report-receipt bounds is already documented. The description adds only the conceptual link between the 'arrival window' and the eta pair; it gives no extra format or interaction detail beyond the schema.

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?

States a specific verb and resource ('Get vessels') plus a precise selection rule: reported destination equals this port and declared ETA falls in the arrival window. The clause 'own reported destination ... not predicted' sharply separates it from ETA-prediction or position-based siblings such as get_vessel_eta or get_vessels_in_radius, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The arrival-window framing implies when the tool is appropriate (planning inbound traffic to a port), but there is no explicit 'use this instead of X' routing or any stated exclusion. An agent must infer that per-vessel lookups belong to get_vessel_eta and that past arrivals belong to port events tools.

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