feat(telemetry): put the tool-result bound on the span, not only in a log #643

Merged

coilyco-ops merged 1 commit from coilyco-ops/a-bound-the-trace-can-see into main

2026-08-13 17:48:00 +00:00

AGit

coilyco-ops commented

2026-08-13 17:46:47 +00:00

Member

closes #640 - the tool span ended before the bound was applied, so a truncation could only ever reach a log. Also fixes a loss figure that was wrong for any multibyte result.

coilyco-ops added 1 commit

2026-08-13 17:46:47 +00:00

feat(telemetry): put the tool-result bound on the span, not only in a log

ci / image-build (pull_request) Successful in 23s

Details

ci / test (pull_request) Successful in 38s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

885553c052

The tool span was ended before boundToolResult ran, so a truncation could never
be an attribute on it. It reached a log line and nothing else, and a log line
cannot be joined to the trace a reader is holding. That is the gap sirens-echo#570
closed for tool outcomes, still open for tool truncation.

The cost showed up on sirens-echo#635: establishing that 87 percent of a Steam
library was dropped took a log search and then two YAML files to learn what the
cap had been. None of it was answerable from the trace.

The bound now runs before the span ends, so mcp.tool.limit_bytes and
mcp.tool.truncated are on every tool call, true or false. Absence is not
something a reader should have to interpret.

The spill stays after the span ends. It writes a file, and folding a disk write
into that span would report as tool latency.

boundToolResult returns the delivered byte count. It walks back to a rune
boundary, so the cut can land below the limit, and a caller subtracting the
limit reports the loss wrongly for any multibyte result. The bounded record now
carries limit_bytes and a dropped_bytes computed from the real cut.

That subtraction is why 635 measured 16,568 delivered against a 16,384 cap and
reasonably concluded the value had moved. It had not: the cap bounds the payload
and the truncation and spill notices are appended after it.

No bound changes and nothing a member sees changes. The sizing question is
sirens-echo#635 and sirens-echo#362, and this is worth doing whichever way those
numbers go.

closes #640

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-13 17:46:47 +00:00

coilyco-ops referenced this pull request

2026-08-13 17:47:07 +00:00

A truncated tool result cannot reach the trace, because the tool span is closed before the bound is applied #640

coilyco-ops referenced this pull request

2026-08-13 17:47:25 +00:00

A tool result that says it saw 2 percent of the data becomes a reply that says none exists #449

coilyco-ops merged commit 550eeefb94 into main

2026-08-13 17:48:00 +00:00

coilyco-ops referenced this pull request from a commit

2026-08-13 17:48:01 +00:00