Gangway AIS

Vessels near a point or vessel

vessels_near

Read-onlyIdempotent

Vessels within a radius of a position or of another vessel, nearest first, each with her distance in nautical miles and true bearing from the centre. It asks for the square around the circle, which must fit your plan's largest box (1 square degree on a free account, 4 on Plus, 25 on Pro, 100 on Scale). Credits: 1 for every vessel in that square (at most 200), and 1 more to centre on a vessel. Free accounts too: their answers are 24 hours behind, with a box of at most 1 square degree and 1,000 credits a month; paid plans are live.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "vessels_near"
  }
}

Input Schema

Name	Required	Description
`lat`	No	Latitude in decimal degrees, north positive
`lon`	No	Longitude in decimal degrees, east positive
`mmsi`	No	Or centre on this vessel's last position
`limit`	No	At most this many vessels (default 25)
`max_age`	No	Only vessels heard within this time, such as 90m or 24h (default 24h)
`radius_nm`	No	Radius in nautical miles (default 10, at most 30)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only declare it a safe, idempotent, open-world read; the description adds the material economics and freshness facts an agent needs: credit cost per vessel in the square (cap 200), an extra credit to centre on a vessel, plan-dependent box limits (1/4/25/100 square degrees), and that free-account answers lag 24 hours while paid plans are live. Those are exactly the behavioural traits structured fields cannot express.

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?

Dense but front-loaded: what it returns and in what order comes first, then the cost/limits caveats. The long parenthetical sentences ('Free accounts too: their answers are 24 hours behind...') are readable but slightly tangled; a bulleted cost/limit block would scan faster. Little outright waste.

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 no output schema, the description still tells the agent the shape of each result (distance in nautical miles, true bearing, nearest first), the maximum result count, staleness, and the plan-imposed box constraint that can cause a request to fail. For a six-parameter read tool, nothing essential is missing.

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 goes beyond it by explaining the relationship between the parameters: the search is executed as a square around the circle that must fit the plan's largest box, and centring on mmsi instead of lat/lon carries an extra credit. It does not restate the numeric ranges or defaults, correctly leaving those to 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?

The definition names a concrete verb and resource ('vessels within a radius of a position or of another vessel') and adds the ordering and per-result fields ('nearest first, each with her distance in nautical miles and true bearing from the centre'). That is enough to distinguish it from a box/area or port-scoped query, but it never names a sibling such as vessels_in_area or port_vessels to make the boundary explicit.

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?

Usage is implied rather than stated: the agent can infer this is the radius/proximity query and that mmsi centres on a tracked vessel, but there is no when-to-use, when-not-to-use, or pointer to the alternative area/port search tools. The plan-tier box constraint is a caveat on use, not guidance on selecting this tool.

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

All Gangway 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.

Resources

Need Help?