Discrete MCP tools vs execute_code: when each wins

When we wanted our boat agents to read SignalK — wind, position, battery,

depth — over MCP, there was already a capable server for it:



for exactly that reason.

We built a separate server anyway:

about

why this belongs in the tool layer and not the prompt: prompt-level formatting

rules are model-dependent and leak. With execute_code, the model touches raw

SignalK values (SI units, decimal degrees, ISO timestamps) on every query, so

every query is a fresh chance to mispronounce the data. With discrete tools,

the raw values never reach the model at all.

That second point keeps proving itself. The same week we wrote this, we

watched a capable cloud model restyle a coordinate string three different

ways through three increasingly strict prompt instructions — and stop only

when the tool returned one pre-assembled sentence to relay. Models reformat

whatever they're allowed to reassemble. Tools that want deterministic output

must hand over finished strings.

So which one do you want?

Neither column is "better." If you're driving SignalK with a frontier model

and want maximum flexibility, use VesselSense — genuinely. If you want

simple, reliable, speakable tools for a voice-first agent, that's what

signalk-mcp is for.

The deeper takeaway isn't about boats: tool design is model-targeting.

The same backend deserves a different MCP surface depending on who's calling.

Token-efficient power tools for big models; validated, pre-formatted,

single-purpose tools for small ones. Pick the surface for the agent you

actually run.