feat(telemetry): say whether a tool listing left the process #525

Merged

coilyco-ops merged 1 commit from coilyco-ops/say-whether-a-listing-left-the-process into main

2026-08-13 15:14:25 +00:00

AGit

coilyco-ops commented

2026-08-13 15:13:14 +00:00

Member

closes #520 - the mcp.tools.list span wraps the lookup, so after the cache landed counting spans reported one listing per turn against about five real round trips in three hours.

coilyco-ops added 1 commit

2026-08-13 15:13:14 +00:00

feat(telemetry): say whether a tool listing left the process

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

Details

ci / test (pull_request) Successful in 34s

Details

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

Details

ci / publish-observed (pull_request) Has been skipped

Details

bd31e36d9b

The mcp.tools.list span wraps the call site, so it is emitted once per turn
whether or not anything reached the network. Before the roster cache those were
the same number and the count was a fair proxy. They are not the same number
now.

Measured on the deployment over three hours: 16 mcp.tools.list spans against 15
community.turn spans, of which only 5 were slower than 10ms. Eleven never left
the process. So the count still reads one listing per turn, which is the
signature of the defect the cache fixed, while the service was making about five
round trips in three hours.

Anyone re-running the query from sirens-echo#163 gets 1:1 and concludes nothing
changed. I concluded that myself until the duration distribution changed my
mind: a cache hit was around 0.1ms and a round trip around 60ms.

A 500x gap was standing in for a field that did not exist, and reading it is
correct only until a server answers quickly or the process runs slowly. So the
span states it. mcp.tools.listed counts the servers that actually listed and
mcp.tools.cached is true when none did.

readyLocked already knew, since it returns early when the cache is fresh. It now
reports that rather than discarding it, which is the same shape as recording a
tool outcome where the call completes instead of reconstructing it later.

The attribute rather than dropping the span for a cache hit: the count being
wrong is what caused this, and a filter is cheaper than a lost signal. The
alternative is recorded on the issue.

docs/sirens-echo-mcp-roster.md is at its 80-line cap, so the telemetry has its
own doc rather than a paragraph that would not fit. That is the fourth file at
its cap today, noted on sirens-echo#471 rather than fixed here.

closes #520

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 15:13:14 +00:00

coilyco-ops referenced this pull request

2026-08-13 15:13:38 +00:00

The response-service inventory is 42 characters from its cap, so a shipped capability cannot be recorded in it #471

coilyco-ops merged commit d58092fa31 into main

2026-08-13 15:14:25 +00:00

coilyco-ops referenced this pull request from a commit

2026-08-13 15:14:25 +00:00

Merge pull request 'feat(telemetry): say whether a tool listing left the process' (#525) from coilyco-ops/say-whether-a-listing-left-the-process into main

coilyco-ops referenced this pull request

2026-08-13 15:28:30 +00:00