Datalastic Vessel Tracking & Maritime Intelligence

Find vessels (registry search)

find_vessels

Search the vessel registry by any combination of name (optionally fuzzy), type, flag country, dimensions, tonnage, or year built — no MMSI or IMO needed. Returns up to 500 static specification records per page (tonnage, dimensions, year built, home port, callsign, etc.) — this is reference data, NOT live position. Provide at least one search criterion; use the response's next token via the next argument to page. Credits: 1 per vessel found. For a vessel's live position use get_vessel; for vessels currently in an area use get_vessels_in_radius.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Vessel name to search for. Combine with fuzzy for similar-name matching.
`next`	No	Pagination token from a previous response's next field, to fetch the next page (up to 500 results per page).
`type`	No	Filter by vessel type (e.g. Cargo, Tanker).
`fuzzy`	No	If true, match similar/approximate names; if false (default) the name must match exactly. Only meaningful together with name.
`length_max`	No	Maximum length (meters).
`length_min`	No	Minimum length (meters).
`breadth_max`	No	Maximum breadth (meters).
`breadth_min`	No	Minimum breadth (meters).
`country_iso`	No	Filter by flag country, 2-letter ISO code (e.g. MT).
`type_specific`	No	Filter by vessel subtype (e.g. Bulk Carrier).
`deadweight_max`	No	Maximum deadweight (tonnes).
`deadweight_min`	No	Minimum deadweight (tonnes).
`year_built_max`	No	Latest year built.
`year_built_min`	No	Earliest year built.
`gross_tonnage_max`	No	Maximum gross tonnage.
`gross_tonnage_min`	No	Minimum gross tonnage.
`include_unknown_type`	No	Include vessels with no/unknown type. Maps to the API's _empty_.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`next`	Yes
`vessels`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description fully bears the burden. It discloses that the tool returns static specification records (reference data, not live position), pagination limits, and credits per vessel. It lacks explicit mention of read-only nature, but it is implied by the 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 about 4 sentences, front-loaded with the main purpose, and concisely covers key details. Every sentence adds value, with no wasted words.

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 (17 parameters) and the presence of an output schema, the description is complete. It covers the type of data returned, pagination, credits, and usage prerequisites. An output schema exists, so return values are handled there.

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 baseline is 3. The description adds context like 'no MMSI or IMO needed' and 'at least one search criterion', but the schema already documents each parameter. The added value is marginal but sufficient.

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: searching the vessel registry by multiple criteria. It specifies the verb 'search' and the resource 'vessel registry', and distinguishes from siblings like get_vessel (live position) and get_vessels_in_radius (area search).

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?

The description explicitly tells when to use this tool (for reference data), when not to use it (for live positions or area vessels), and provides alternatives like get_vessel and get_vessels_in_radius. It also gives requirements like needing at least one search criterion and pagination guidance using 'next' token.

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

All Datalastic Vessel Tracking & Maritime Intelligence tools Inspect

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.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: vessel tracking (get_vessel, get_vessel_pro, get_vessel_history, get_vessel_info, estimated_vessel_position), registry search (find_vessels, find_ports), port details (get_port), weather (get_weather), sea route (sea_route), async reports (report_*), and intelligence modules (intel_*). Even similar tools like find_vessels vs get_vessel are well-differentiated by their descriptions.

Naming Consistency5/5

All tool names follow a consistent lowercase underscore pattern with a verb_noun structure (e.g., get_vessel, find_ports, sea_route). The intel_* tools use a uniform prefix for intelligence operations, maintaining predictability across the set.

Tool Count3/5

With 25 tools, this server is at the upper boundary of the borderline range. While the tools are well-organized and necessary for the comprehensive maritime intelligence domain, the count feels slightly heavy compared to an ideal 3-15 tool scope.

Completeness5/5

The tool surface is remarkably complete: it covers vessel tracking (live, historic, estimated), registry search, port details, weather, sea route calculation, async report management, and a full suite of intelligence reports (casualties, inspections, ownership, etc.). There are no obvious gaps for maritime vessel tracking and intelligence tasks.

Find vessels (registry search)

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources