We run a prime directive on this stack: if a usable tool already exists, improve it; build our own only as a last resort, and when you keep your own, record why each alternative failed. This post is that audit for .) A server that returns raw API JSON pushes that formatting onto the model — the exact layer that fails. Generic servers return raw or near-raw payloads. That's correct for a frontier model in a chat window and disqualifying for ours.
And: tool-count bloat
4 tools vs. ~13, ~12, 25+. The MCP field has converged on a real number here: tool-selection accuracy on smaller models degrades as the surface grows, and the common advice is to keep a server in the 5–8 range and split domains past ~15. A curated 4-tool surface isn't minimalism for its own sake — it's the thing that keeps an 8B picking the right tool.
The decision: keep, with receipts
Per the directive, every alternative gets a recorded reason:
open-meteo-mcp — covers only the Open-Meteo forecast leg, returns raw JSON (breaks the display contract), ~13 tools. No buoys, no premium, no observations.
weather-mcp/weather-mcp — same gaps, more tools, marine is forecast-only by its own README.
NOAA-Tides — CO-OPS water levels and currents; overlaps a tide server's domain, not a wave-observation server's. No buoy waves, no forecasts.
Splitting (someone's forecast + our buoys) — doubles config surface and the most-called tool loses the display contract.
Keep ours. Now close its biggest documented gap.
The honest twist: a library-level adopt we also rejected
"Prefer adopting" doesn't stop at servers — there's a library that does exactly the NDBC parsing we hand-roll: . Go read the three servers above too — all good work, just built for a different boat.
SOCIAL SHARE CARD GENERATOR