Live AIS vessel positions by MMSI, name, area, or radius, plus coverage. No sign-in, no key.
Scored across 5 tools
Each tool targets a distinct lookup mode: bounding-box area, radius/near, coverage/station status, direct MMSI lookup, and name-based search. The spatial pair is clearly differentiated by shape and use case, and the name-search description explicitly routes to get_vessels.
All names use a consistent snake_case verb_noun structure: find_vessels_in_area, find_vessels_near, get_coverage, get_vessels, search_vessels_by_name. The verbs align with operation type—find for spatial searches, get for direct retrieval, search for text lookup—making the naming pattern predictable.
Five tools is a well-scoped set for a live AIS lookup service: two spatial queries, one identifier lookup, one name resolver, and one coverage checker. Each tool serves a distinct workflow without redundancy or unnecessary bloat.
The core workflows are fully covered: discover vessels by area or proximity, resolve a name to MMSI, retrieve vessel details by MMSI, and verify coverage before declaring an area empty. Possible gaps like historical tracks or detailed station metadata are outside the server's stated live-position scope.
Vessels currently inside a latitude/longitude bounding box, newest report first, with optional kind and ship-type filters. Use for what is in a port, a strait, or a stretch of coast. Anonymous calls may cover 100 square degrees per call.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | Yes | ||
| kind | No | only this kind: vessel, aton (aid to navigation), base (base station), or sar (search and rescue aircraft) | |
| limit | No | rows to return: default 50, maximum 200 | |
| types | No | only these ITU ship type codes, e.g. 30 fishing, 36 sailing, 37 pleasure craft, 52 tug, 60 passenger, 70 cargo, 80 tanker; a code ending in 0 matches its decade, so 70 matches 70 to 79 |
| Name | Required | Description |
|---|---|---|
| total | Yes | vessels matched before the limit was applied |
| vessels | Yes | |
| truncated | Yes | true when total exceeds the rows returned; narrow the query or raise limit |
| attribution | Yes | credit line per source kind in the rows, to show with the data |
| unknown_mmsi | No | requested MMSIs not heard in the last 30 minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and idempotentHint, and the description adds useful behavioral content beyond that: results are 'currently inside' at call time and 'newest report first'. It also discloses the anonymous-call area limit of 100 square degrees, which is not present in annotations or schema. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences each carry distinct value: the core behavior, the intended use cases, and an important constraint. It is front-loaded with the most important information and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations, an output schema, and 75% parameter-documentation coverage, the description is largely complete: it explains ordering, areal scope, use context, and a rate/area constraint. It could have added a sentence about pagination or the limit parameter, but the schema already covers those defaults and maximums.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so most parameter meaning is already available in the schema. The description adds no deeper semantics for the parameters themselves beyond summarizing 'optional kind and ship-type filters', which is lighter than the schema's own examples and constraints. It does not compensate for the remaining 25% of undocumented schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Vessels currently inside a latitude/longitude bounding box', and adds ordering and filter details. It clearly distinguishes this tool from near-based, name-based, and generic vessel lookups by its bounding-box scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use for what is in a port, a strait, or a stretch of coast' gives clear context for when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the use-case guidance is actionable and the boundary constraint is communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vessels within a radius (default 10 NM, maximum 50) of a point or of another vessel, nearest first, each with distance and bearing from the centre. Use for what is near this position or what is around vessel X.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | centre latitude, degrees; give lat and lon, or mmsi | |
| lon | No | centre longitude, degrees | |
| kind | No | only this kind: vessel, aton, base, or sar | |
| mmsi | No | centre on this vessel's last position instead of lat and lon; the vessel itself is left out of the results | |
| limit | No | rows to return: default 50, maximum 200 | |
| types | No | only these ITU ship type codes; a code ending in 0 matches its decade | |
| radius_nm | No | search radius in nautical miles: default 10, maximum 50 |
| Name | Required | Description |
|---|---|---|
| total | Yes | vessels matched before the limit was applied |
| vessels | Yes | |
| truncated | Yes | true when total exceeds the rows returned; narrow the query or raise limit |
| attribution | Yes | credit line per source kind in the rows, to show with the data |
| unknown_mmsi | No | requested MMSIs not heard in the last 30 minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavior beyond the annotations: results are sorted nearest first, each includes distance and bearing, and the center vessel is excluded when using mmsi. The read-only and idempotent hints are already in the annotations, so the description does not need to restate them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the first states the core behavior and result shape, the second gives direct usage intent. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only spatial query, the description combined with the 100%-covered schema, annotations, and output schema is complete. It covers the center modes, radius constraints, result ordering, and distance/bearing output without needing to re-explain every parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter already has a clear description. The description mostly summarizes what the schema states, such as default and maximum radius and the choice between lat/lon and mmsi, without adding substantial new parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: finding vessels within a radius of either a point or another vessel. It also distinguishes this from the sibling area-based lookup by emphasizing 'radius' and by naming the two center modes (position or vessel).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use the tool: 'Use for what is near this position or what is around vessel X.' However, it does not mention when not to use it or name alternatives such as find_vessels_in_area for area searches, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where Open Waters AIS is hearing AIS right now: sources, stations, freshness, and vessel counts. Pass a bounding box to learn which stations cover it and how many vessels are in it, or a station id for that station's numbers. Call this before saying a region has no traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | report the stations covering this box and the vessels currently in it | |
| station | No | a station id from an earlier result, for that station's numbers |
| Name | Required | Description |
|---|---|---|
| area | No | |
| note | No | |
| time | Yes | |
| sources | Yes | |
| station | No | |
| summary | Yes | |
| vessels | Yes | |
| stations | Yes | |
| events_per_second | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, so no contradiction exists and the safety burden is lifted. The description adds useful behavioral context: it reports a live snapshot ('right now'), includes freshness, and describes what the bbox versus station modes return, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler, and the key purpose is stated first. The actionable usage rule is front-loaded near the end of the description, making it easy to scan while keeping the main semantics up front.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its small size, the definition fully covers what the tool does, what inputs it accepts, what kind of information the caller should expect, and when it should be invoked. With an output schema present and only two optional parameters, nothing essential is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented in the schema. The description reinforces the split between bbox and station modes but does not add substantial meaning beyond what the structured descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: reporting where AIS is currently being heard, plus sources, stations, freshness, and vessel counts. It clearly distinguishes this from the vessel-search siblings by focusing on coverage infrastructure rather than finding individual vessels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit call patterns: pass a bounding box for station coverage and vessel counts, or a station id for station-level numbers. The closing instruction to call it before claiming a region has no traffic provides strong contextual guidance, though it does not explicitly name sibling alternatives to exclude.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current position and details of specific vessels by MMSI (Maritime Mobile Service Identity): the last report heard for each, and which MMSIs have not been heard in the last 30 minutes. Use search_vessels_by_name first when you only have a name.
| Name | Required | Description | Default |
|---|---|---|---|
| mmsi | Yes | MMSIs to look up; anonymous calls may pass 10, a personal token 50 |
| Name | Required | Description |
|---|---|---|
| total | Yes | vessels matched before the limit was applied |
| vessels | Yes | |
| truncated | Yes | true when total exceeds the rows returned; narrow the query or raise limit |
| attribution | Yes | credit line per source kind in the rows, to show with the data |
| unknown_mmsi | No | requested MMSIs not heard in the last 30 minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, and the description adds meaningful behavioral detail: it returns the last heard report and indicates which MMSIs were not heard recently. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first front-loads the purpose and output scope, the second gives routing guidance. No filler or redundant restatement of the tool title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, full schema coverage, an output schema, and safety annotations, the description covers the key usage context: what to retrieve and when to use the sibling instead. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents the mmsi parameter, including anonymous/personal token limits. The description adds little beyond restating that lookups are by MMSI, so the baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific operation — retrieving current position and details by MMSI — and explicitly distinguishes it from search_vessels_by_name. It also names the resource (vessels by MMSI) and adds the unique 'not heard in 30 minutes' detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to use search_vessels_by_name first when only a name is available, routing between alternatives. This is clear when-to-use guidance for the main decision point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vessels whose name contains the text, case-insensitive, among vessels heard in the last 30 minutes. Use to turn a name into an MMSI, then get_vessels or find_vessels_near for detail. An optional bounding box narrows the search.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | only vessels whose last position is inside this box | |
| name | Yes | text to find in the vessel name, at least 2 characters, case-insensitive | |
| limit | No | rows to return: default 50, maximum 200 |
| Name | Required | Description |
|---|---|---|
| total | Yes | vessels matched before the limit was applied |
| vessels | Yes | |
| truncated | Yes | true when total exceeds the rows returned; narrow the query or raise limit |
| attribution | Yes | credit line per source kind in the rows, to show with the data |
| unknown_mmsi | No | requested MMSIs not heard in the last 30 minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds behavioral context beyond annotations: the 30-minute recency filter, case-insensitive substring matching, and the effect of an optional bounding box. This enriches the agent's understanding of what the tool actually does without repeating annotation information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no waste. The core behavior is front-loaded in the first sentence, the usage guidance follows, and the optional parameter note is last. Every sentence earns its place, and the structure is scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema present, complete parameter descriptions in the schema, and annotations covering safety, the description adds the remaining critical context: the 30-minute time window, substring matching semantics, and the intended use case. An agent has everything needed to call this tool correctly without additional guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (name, bbox, limit) fully described in the schema. The description only adds a generic note about the bounding box ('An optional bounding box narrows the search'), which is already more precisely stated in the schema ('only vessels whose last position is inside this box'). Thus the description adds minimal value beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: search vessels by name substring, case-insensitive, within a 30-minute window. It clearly identifies the resource (vessels) and the filtering criteria, and it distinguishes itself from siblings by naming get_vessels and find_vessels_near for follow-up detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to turn a name into an MMSI, then get_vessels or find_vessels_near for detail,' which gives a clear primary use case and names alternatives. It does not explicitly state when not to use it, but the guidance is sufficient for an agent to understand the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_vessels_in_areafind_vessels_nearget_coverageget_vesselssearch_vessels_by_nameVessel Tracking — live worldwide ship positions from AIS.
Vessel tracking for 750,000+ ships, with ownership, inspections, port records, routes, and more.
Live AIS vessel tracking for the Baltic Sea and Gulf of Finland via Fintraffic's open Digitraffic
Datalastic MCP — live AIS vessel positions (datalastic.com)
Add one secure layer between your agents and this server.
