Several tools have heavily overlapping purposes, especially the port event family: search_port_events_by_vessel, get_port_events_by_vessel, search_port_events_by_port, get_port_events, and list_port_events all query similar event data with only subtle filter differences. get_vessel_last_port_event, get_vessel_position, and get_vessel_positions_batch also create boundary confusion. An agent could easily select the wrong tool despite the descriptions.

The tools mostly use snake_case verb_noun naming with get_, search_, and list_ prefixes, but the mix of verbs is inconsistent for similar actions. For example, port events are exposed as get_port_events, search_port_events_by_vessel, get_port_events_by_vessel, and list_port_events, making the naming pattern feel arbitrary. Still, the convention is readable and not chaotic.

Nineteen tools is on the heavy side for a vessel/port data API, especially since several tools appear to cover nearly the same port event queries. The core domain is broad enough to justify many endpoints, but the overlapping tools inflate the count and make the surface feel larger than necessary.

The server covers the main read-only vessel and port domain well: vessel lookup, positions, ETA, emissions, casualties, port details, port events, and area/radius queries are all present. Minor gaps exist, such as no historical vessel track or port call summary endpoint, but agents can generally accomplish core workflows without dead ends.