Global Fishing Watch MCP server

@pipeworx/global-fishing-watch

Global Fishing Watch API v3 — AIS-derived vessel identity, at-sea events (apparent fishing, encounters, loitering, port visits, AIS gaps) and aggregated apparent fishing effort.

Part of Pipeworx — an MCP gateway connecting AI agents to 1679+ live data sources.

Tools

identity by name, MMSI, IMO or call sign.

• gfwfishvesselssearch(query, datasets?, limit?, offset?, _apiKey) — vessel

offset?, _apiKey) — events over a date range.

• gfwfishevents(startdate, enddate, vesselid?, event_type?, limit?,

temporalresolution?, spatialresolution?, datasets?, _apiKey) — apparent fishing effort aggregated over a bounding box.

• gfwfish4wingsreport(bbox, startdate, enddate, group_by?,

Auth

Platform-backed since 2026-09-18. PLATFORMGFWFISHINGTOKEN is in the encrypted keystore (GFW API application "pipeworx", non-commercial intended use); the gateway injects it as apiKey, and a caller may pass their own instead. Every v3 endpoint requires a Bearer token — there is no keyless or demo path. Free non-commercial tokens: .

Distinct from PLATFORMGFWKEY, which is Global Forest Watch — different organisation, different API, similar abbreviation.

licence: non-commercial is set on the pack: GFW data is free for non-commercial use and commercial use needs their permission.

Data sources

region geometry goes in the body, the resolution/grouping in the query string)

• (POST; the

A 401 from this API proves nothing about the path. An unauthenticated request to any path — including one that does not exist, verified against /v3/zzz-not-a-path on 2026-09-17 — answers 401 {"error":"invalid token"}. That is why the shapes shipped on 2026-09-17 were unverifiable, and why the first probe on a real token returned a 422.

The two paging schemes are different, and mixing them is the 422. /v3/vessels/search pages by CURSOR: the response carries since, you pass it back as since, and sending offset is rejected 422 Unprocessable Entity. /v3/events pages the ordinary way — offset and limit are both required, and the response carries nextOffset. Do not unify them.

Other shape facts, each from the v3 docs and then proved live (fleet #2245):

Shortened. The full README is on GitHub.