Skip to main content
Glama
ariefrsee

Maritime Vessel Data MCP Server

traffic_density

Retrieve vessel traffic density as grid cells showing distinct vessels and total position counts for a region or bounding box over a chosen time window.

Instructions

Where vessels have actually been, as a grid of counts.

Read this as coverage as much as traffic. It shows where positions were received, so an empty cell means either that no ship went there or that nothing was listening. Port Klang reads as empty on this map and it is one of the busiest ports in the world.

Each cell reports distinct vessels and total positions separately, because they answer different questions: one ship anchored for two days makes hundreds of positions in a single cell, which is a fact about that ship and not about how busy the cell is.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bboxNoArea to report instead, as 'south,west,north,east'.
daysNoHow far back to include, in days, up to the 90 day retention window.
regionNoRegion key to report, for example 'malacca-strait'. Call list_regions for the keys. Ignored when bbox is given.
cell_degreesNoGrid cell size in degrees. 0.02 is about 1.2 nautical miles. Smaller resolves more and costs more.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it explains that cells represent received positions, that empty cells are ambiguous ('either that no ship went there or that nothing was listening'), and that distinct vessels and total positions answer different questions. These are genuine behavioral caveats beyond what the schema provides.

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?

Three tight paragraphs with a front-loaded one-line summary. The Port Klang example earns its place by making the coverage-vs-traffic distinction concrete, and the final paragraph clarifies a subtle output distinction that would otherwise be easy to misinterpret.

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?

Given an output schema exists and all parameters are fully documented in the schema, the description covers the key interpretive risks: sparse-coverage bias, empty-cell ambiguity, and the different meanings of distinct vessels vs total positions. It is slightly incomplete only in not addressing when to choose this over closely related sibling tools.

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%: bbox, days, region, and cell_degrees all have meaningful descriptions, defaults, and bounds. The tool description does not add param-specific semantics, so the baseline of 3 is appropriate.

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 opening line, 'Where vessels have actually been, as a grid of counts,' clearly communicates the tool's resource and output type. It distinguishes this from port-focused siblings like congestion or anchorages by framing it as historical position coverage, though it never names a specific sibling or explicit verb like 'reports' or 'computes'.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like vessels_in_area, congestion, or vessel_track. The 'Read this as coverage as much as traffic' warning is about interpreting results, not about selecting the tool, and no when-to-use or when-not-to-use conditions are given.

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