An agent reads who polls the telemetry and how fast through the MCP system tool and GET /api/v1/telemetry/system, as /system shows #9095

The MCP system tool and GET /api/v1/telemetry/system now return readers: the same readerPaces() rows /system draws (route, reader, reads, meanIntervalMs, tooFast), most reads first.

The new tests, test/telemetry-reads-readers.test.ts, test/mcp-size.test.ts, test/telemetry-reads-pace.test.ts, test/system-telemetry.test.ts and the OpenAPI tests pass. So do tsc and scripts/gate.ts. I did not run the full suite.

• What changed: a new systemWithReaders() in src/system/telemetry.ts adds the rows to the existing system view. Both the tool and the route use it, behind the same gate as before: a forge admin, or an agent granted telemetry:read. Anyone else gets the existing refusal and no reader names.
• Order of counting: the API route used to count the read before building the reply, so a reply listing readers would have counted itself. telemetryRead in src/http/api.ts now counts after the body is built. This applies to the flow route too, with no visible change there. The MCP system tool did not count reads at all before. It now calls countRead("system", …) after building its answer, so its reads show up in the rows.
• Docs: the tool's doc line, the OpenAPI summary for the route and docs/features/telemetry-readers.md now say where agents read it.
• Tests: the new test counts flow reads with countRead, then calls the MCP tool and the API route. It expects the same rows, including tooFast: true for a flow reader faster than every 5 s. It pins that a read is not in its own readers, and that an agent without the grant gets a 403 with no reader names.

I put the test in a new sibling file rather than test/telemetry-reads-pace.test.ts. I did not add a new tool or raise any MCP size ceiling.

Closes #9088

The MCP system tool and GET /api/v1/telemetry/system now return readers: the same readerPaces() rows /system draws (route, reader, reads, meanIntervalMs, tooFast), most reads first.

The new tests, test/telemetry-reads-readers.test.ts, test/mcp-size.test.ts, test/telemetry-reads-pace.test.ts, test/system-telemetry.test.ts and the OpenAPI tests pass. So do tsc and scripts/gate.ts. I did not run the full suite.

• What changed: a new systemWithReaders() in src/system/telemetry.ts adds the rows to the existing system view. Both the tool and the route use it, behind the same gate as before: a forge admin, or an agent granted telemetry:read. Anyone else gets the existing refusal and no reader names.
• Order of counting: the API route used to count the read before building the reply, so a reply listing readers would have counted itself. telemetryRead in src/http/api.ts now counts after the body is built. This applies to the flow route too, with no visible change there. The MCP system tool did not count reads at all before. It now calls countRead("system", …) after building its answer, so its reads show up in the rows.
• Docs: the tool's doc line, the OpenAPI summary for the route and docs/features/telemetry-readers.md now say where agents read it.
• Tests: the new test counts flow reads with countRead, then calls the MCP tool and the API route. It expects the same rows, including tooFast: true for a flow reader faster than every 5 s. It pins that a read is not in its own readers, and that an agent without the grant gets a 403 with no reader names.

I put the test in a new sibling file rather than test/telemetry-reads-pace.test.ts. I did not add a new tool or raise any MCP size ceiling.

The MCP system tool and GET /api/v1/telemetry/system now return readers, the same rows /system draws: route, reader, reads, meanIntervalMs, tooFast, most reads first.

The check failed on the gate rule "say how to try it on the preview": no commit message had a Try: line. I added an empty commit with one and pushed. bun scripts/gate.ts printed nothing after it. The forge's check has not run on the new push yet.

What changed:

• Gate: the endpoint stays behind the existing telemetry gate (a forge admin, or an agent granted telemetry:read). Anyone else gets the existing refusal and no reader names.
• Counting order: a read is counted after its answer is built, so it does not appear in its own readers. The route in src/http/api.ts now counts after building the body, which also applies to the flow route with no visible change there. The MCP system tool did not count reads before and now does.
• Docs and tests: the tool's doc line, the OpenAPI summary and docs/features/telemetry-readers.md name the field. test/telemetry-reads-readers.test.ts counts reads with countRead and expects the MCP tool and the API route to return the same rows, including tooFast: true for a fast flow reader.

I put the test in a new sibling file rather than test/telemetry-reads-pace.test.ts. I did not add a tool or raise any MCP size ceiling.

To try it: call GET /api/v1/telemetry/system on the preview with an admin or telemetry:read token and read the readers array, or call the MCP system tool.

Left #9088 open: 1 unticked item remain (bun test passes.).