github activeing123/mcptoon v0.8.1

latest releases: v0.8.36, v0.8.35, v0.8.34...
one month ago

v0.8.1

A patch for two bugs found by people running mcptoon against real clients. Both
made a whole class of tools unusable rather than merely wrong.

Fixed

mcptoon serve dropped the structured result of an upstream tool (#22). A tool
whose tools/list entry advertises an outputSchema must answer with a matching
structuredContent (MCP 2025-06-18+), but the gateway routed every call through
pool.call(), which unwraps the envelope down to the payload — so the field never
reached the client and strict hosts rejected the result even though the upstream
server behaved correctly. serve now keeps the complete envelope and carries
structuredContent through.

Usage accounting and --format compression still run on the payload view, so
neither the reported numbers nor the compressed text change; pools that predate
call_full fall back to call. We kept advertising outputSchema rather than
dropping it, which would have traded a spec violation for the loss of the typed
contract for every client.

mcptoon_health reported uptimeSeconds: -0.0 (#23). A tiny negative elapsed
time rounds to -0.0, which is legal JSON but not value-preserving for a JS client
— JSON.parse("-0.0") is -0, which stringifies back to "0" — so hosts that
round-trip a tool result to prove it is lossless rejected the whole response.
Uptime is now clamped at 0.

Impact

Under the reporting client, #22 left 5 of 12 upstream tools callable — every
failure was a tool that declares an outputSchema — and #23 failed
mcptoon_health on every call.

A note on how this was verified

Fixing #22 was not a one-line change. A payload that itself carries a content
key — which is what filesystem's list_directory declares as its output schema,
and one of the reporter's own tools — is read by _make_tool_result() as an
already-wrapped result and returned as that same object, so attaching
structuredContent nested the result inside itself. The unit tests, which fake
the pool, could not reach that; an end-to-end test driving a real stdio MCP
server caught it.

Both fixes are pinned by regression tests that were confirmed to fail against the
old code before the fix landed.

Thanks

GIGIGIGIbaby reported both bugs, and the decisive check — calling the same
upstream server directly and getting structuredContent back — is what proved the
field was lost in the gateway and not absent upstream.

Full suite: 1470 passed, 2 skipped. Zero dependencies.

Don't miss a new mcptoon release

NewReleases is sending notifications on new releases.