AetherLink SDR MCP

by N-Erickson

Overview Schema Source Related Servers Discussions Admin

Python

Local

marine_get_vessels

Retrieve a list of tracked marine vessels, filtered by maximum age, to monitor nearby vessel activity from SDR data.

Instructions

Get list of tracked vessels

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": "marine_get_vessels"
  }
}

Input Schema

Name	Required	Description	Default
`max_age`	No	Maximum vessel age in seconds

Output Schema

Name	Required	Description	Default
`active`	No
`vessels`	No
`statistics`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 7, 2026

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It implies a read-only list operation but does not say whether vessels must already be actively tracked, whether results are a snapshot or live, or how max_age affects freshness. The output schema helps with return values, but operational behavior remains undisclosed.

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?

The description is a single front-loaded sentence with no wasted words. Its brevity is mostly appropriate for a simple list tool, though it leaves out useful context that could have been added without bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one optional parameter and an output schema, so the description does not need to explain return values. However, it omits whether tracking must be active and how it relates to the tracking/stopping siblings, leaving meaningful context gaps.

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%, and max_age is fully documented in the input schema with its default and meaning. The description adds no additional parameter semantics beyond that, so the baseline of 3 applies.

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 description states a specific verb and resource: 'Get list of tracked vessels.' It is clear enough to distinguish a read/list operation from sibling mutation tools like marine_track_vessels or marine_stop_tracking, though it does not explicitly name those alternatives.

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 marine_track_vessels or marine_stop_tracking. The listing behavior is implied by 'Get list,' but no prerequisites or exclusions are stated.

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