Skip to main content
Glama
IBM

Chuk MCP Maritime Archives

by IBM

maritime_aggregate_track_speeds

Aggregate and analyze historical daily sailing speeds from logbook positions filtered by region, nationality, wind force, and time period, grouping results by decade, year, direction, or other dimensions to reveal trends.

Instructions

Aggregate daily sailing speeds across all matching CLIWOC tracks.

Computes haversine-based daily speeds from consecutive logbook positions, filters by geographic region, and aggregates by the requested dimension. Returns descriptive statistics per group.

Args: group_by: Grouping dimension. Options: - "decade" — group by decade (e.g., 1750, 1760, ...) - "year" — group by individual year (e.g., 1783, 1784, ...) - "month" — group by month (1-12) - "direction" — group by eastbound/westbound - "nationality" — group by ship nationality (NL, UK, ES, ...) - "beaufort" — group by Beaufort wind force (0-12) lat_min: Minimum latitude for position bounding box lat_max: Maximum latitude for position bounding box lon_min: Minimum longitude for position bounding box lon_max: Maximum longitude for position bounding box nationality: Filter tracks by nationality code (NL, UK, ES, FR, etc.) year_start: Filter tracks starting from this year year_end: Filter tracks ending at this year direction: Filter observations by "eastbound" or "westbound" month_start: Filter by start month (1-12). Supports wrap-around with month_end (e.g., month_start=11, month_end=2 = Nov-Feb) month_end: Filter by end month (1-12). Used with month_start aggregate_by: Unit of analysis — "observation" (default, each daily speed is a data point) or "voyage" (one mean speed per voyage, statistically independent samples) min_speed_km_day: Minimum speed filter (default: 5.0) max_speed_km_day: Maximum speed filter (default: 400.0) wind_force_min: Minimum Beaufort force (0-12). Requires wind data wind_force_max: Maximum Beaufort force (0-12). Requires wind data output_mode: Response format - "json" (default) or "text"

Returns: JSON or text with per-group statistics (n, mean, median, std, 95% CI, percentiles)

Tips for LLMs: - Use lat_min=-50, lat_max=-30 for the Roaring Forties wind belt - group_by="decade" shows speed trends over time - group_by="direction" shows eastbound vs westbound asymmetry - group_by="beaufort" shows speed profiles by wind force - Use aggregate_by="voyage" for statistically independent samples - Use wind_force_min/max to condition on wind strength - Use maritime_compare_speed_groups for significance testing - Use maritime_did_speed_test for direction x period interaction

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
group_byNodecade
lat_minNo
lat_maxNo
lon_minNo
lon_maxNo
nationalityNo
year_startNo
year_endNo
directionNo
month_startNo
month_endNo
aggregate_byNoobservation
min_speed_km_dayNo
max_speed_km_dayNo
wind_force_minNo
wind_force_maxNo
output_modeNojson
Behavior4/5

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

With no annotations, the description carries full burden. It explains the computation, filtering, aggregation, and output statistics (mean, median, std, CI). It does not explicitly state read-only behavior or prerequisites, but for an aggregation tool, transparency is good.

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 well-structured with a summary, parameter list, returns, and tips. Though lengthy, every sentence adds value given the number of parameters and zero schema coverage. It is front-loaded and clear.

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?

Given 17 parameters, no output schema, and no annotations, the description is very complete. It explains all parameters, the output format, and provides usage tips. It also references sibling tools for further analysis, covering the tool's capabilities fully.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate. It lists all 17 parameters with explanations, allowed values, defaults, and constraints (e.g., group_by options, Beaufort range 0-12). This adds significant meaning beyond the schema.

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?

The description clearly states it aggregates daily sailing speeds across CLIWOC tracks, computing haversine-based daily speeds and grouping by dimension. It mentions returns descriptive statistics per group, distinguishing it from siblings like maritime_compute_track_speeds or maritime_aggregate_track_tortuosity.

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

Usage Guidelines5/5

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

It provides explicit tips for when to use specific parameters (e.g., lat_min/lat_max for Roaring Forties) and directs to sibling tools for significance testing and interaction effects, clearly guiding the agent on alternatives and context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/IBM/chuk-mcp-maritime-archives'

If you have feedback or need assistance with the MCP directory API, please join our Discord server