Open Waters AIS

Coverage and sources

get_coverage

Read-onlyIdempotent

Where Open Waters AIS is hearing AIS right now: sources with their current delay, 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. Vessel counts cover the last 30 minutes; max_age widens them, to 7d for the last week or all for every vessel the network has heard. Call this before saying a region has no traffic.

Input Schema

Name	Required	Description
`bbox`	No	report the stations covering this box and the vessels currently in it
`max_age`	No	count vessels heard within this long, network-wide and in bbox, instead of the last 30 minutes: a duration such as 6h, 24h, or 7d, or all for every vessel the network has heard
`station`	No	a station id from an earlier result, for that station's numbers

Output Schema

Name	Required	Description	Default
`area`	No
`note`	No
`time`	Yes
`sources`	Yes
`station`	No
`summary`	Yes
`vessels`	Yes
`stations`	Yes
`events_per_second`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

changedOutput schema / properties / area / properties / stations / items / properties / bbox / description

Previous value: -"extent of the positions this station has heard"New value: +"extent of the positions this station has heard since the server last started; absent until it hears one"

changedOutput schema / properties / station / properties / bbox / description

Previous value: -"extent of the positions this station has heard"New value: +"extent of the positions this station has heard since the server last started; absent until it hears one"

Changed3 schema fields changedOct 8, 2026

changedOutput schema / properties / area / properties / stations / items / properties / vessels / description

Previous value: -"distinct vessels heard in the last 30 minutes"New value: +"distinct vessels whose positions the station heard in the last 30 minutes, its own left out, up to about 7 minutes behind"

changedOutput schema / properties / sources / items / properties / vessels / description

Previous value: -"distinct vessels heard from this source in the last 30 minutes"New value: +"distinct vessels whose positions this source's stations heard in the last 30 minutes, up to about 7 minutes behind"

changedOutput schema / properties / station / properties / vessels / description

Previous value: -"distinct vessels heard in the last 30 minutes"New value: +"distinct vessels whose positions the station heard in the last 30 minutes, its own left out, up to about 7 minutes behind"

Changed8 schema fields changedSep 30, 2026

addedInput schema / properties / max_age

Added value: +{
+  "description": "count vessels heard within this long, network-wide and in bbox, instead of the last 30 minutes: a duration such as 6h, 24h, or 7d, or all for every vessel the network has heard",
+  "type": "string"
+}

changedOutput schema / properties / area / properties / vessels / description

Previous value: -"vessels with a position inside the box"New value: +"vessels whose last known position is inside the box, heard in the last 30 minutes or within max_age"

addedOutput schema / properties / vessels / properties / active

Added value: +{
+  "description": "vessels heard in the last 30 minutes",
+  "type": "integer"
+}

addedOutput schema / properties / vessels / properties / heard

Added value: +{
+  "description": "vessels heard within max_age; present when max_age is given",
+  "type": [
+    "null",
+    "integer"
+  ]
+}

addedOutput schema / properties / vessels / properties / new

Added value: +{
+  "description": "vessels first heard within max_age; present when max_age is a duration",
+  "type": [
+    "null",
+    "integer"
+  ]
+}

changedOutput schema / properties / vessels / properties / total / description

Previous value: -"vessels heard in the last 30 minutes"New value: +"every vessel the network has heard"

addedOutput schema / properties / vessels / properties / with_position / description
```
Added value: +"of the active vessels, those with a position"
```

changedOutput schema / properties / vessels / required

Previous value: -[
-  "total",
-  "with_position"
-]New value: +[
+  "total",
+  "active",
+  "with_position"
+]

Changed1 schema field changedSep 23, 2026

addedOutput schema / properties / sources / items / properties / delay

Added value: +{
+  "additionalProperties": false,
+  "description": "seconds from broadcast to arrival over the last position reports from this source",
+  "properties": {
+    "p50": {
+      "description": "median delay in seconds",
+      "type": "number"
+    },
+    "p99": {
+      "description": "99th percentile delay in seconds",
+      "type": "number"
+    }
+  },
+  "required": [
+    "p50",
+    "p99"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

First observedSep 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses a non-obvious default (counts cover the last 30 minutes), the widening semantics of max_age (up to 7d or 'all'), and a data-completeness caveat that warns against false negatives. That is exactly the behavioral context annotations cannot carry.

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?

Three dense sentences, all load-bearing, with the resource definition front-loaded and the safety caveat closing as a call to action. The opening enumeration of sources/delay/stations/freshness/counts is slightly sprawling but each item is informative.

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?

With an output schema handling return values and annotations covering the safety profile, the description supplies the remaining pieces an agent needs: what selects what, the time-window defaults, and when the data is insufficient to conclude 'no traffic'.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: bbox returns covering stations plus in-box vessel counts, and station refers to an id from an earlier result. max_age's effect on both network-wide and bbox counts is restated with concrete examples.

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?

States a specific verb+resource: reports where the AIS network is hearing traffic — sources, delay, stations, freshness, vessel counts. This clearly separates it from the sibling vessel-lookup tools, which search for individual vessels rather than describing network coverage.

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?

Gives explicit invocation triggers: pass a bbox to learn which stations cover it, pass a station id for that station's numbers, and call it before claiming a region has no traffic. It does not explicitly name or exclude the sibling tools, so routing versus find_vessels_in_area is left implicit.

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

All Open Waters AIS 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.