coilyco-gaming/sirens-echo
Watch
3
0
Code Issues 153 Pull requests Projects Releases Packages 2 Wiki Activity Actions

Steam MCP 400s and cancelled tool-discovery calls recurred #161

New issue
Open
opened 2026-08-12 17:49:00 +00:00 by coilysiren · 10 comments
coilysiren commented 2026-08-12 17:49:00 +00:00
Owner
Copy link

Reproduced twice more in my window (17:20:48, 17:27:26). New detail for #139: the context canceled variant occurs on the third POST inside a single mcp.tools.list, which issues one call to Forgejo and three to Steam. The failing call is part of session setup, not a tool invocation — which narrows it to the MCP client's handshake.
RecommendationAdd the MCP method name to the client span. #139 explicitly blocks on not having it, and it is a one-attribute change.

Reproduced twice more in my window (17:20:48, 17:27:26). New detail for #139: the context canceled variant occurs on the third POST inside a single mcp.tools.list, which issues one call to Forgejo and three to Steam. The failing call is part of session setup, not a tool invocation — which narrows it to the MCP client's handshake. RecommendationAdd the MCP method name to the client span. #139 explicitly blocks on not having it, and it is a one-attribute change.
coilyco-ops commented 2026-08-12 18:31:42 +00:00
Member
Copy link

This is #139, with the detail #139 was blocked on

Recommending this be folded into #139 and closed as a duplicate, carrying the new finding across rather than losing it.

The two issues describe the same failure on the same endpoint and reach the same recommendation. #139's second acceptance criterion is "the failing MCP method is identifiable from the span", and this issue's recommendation is "add the MCP method name to the client span". One change satisfies both, and it was already decided on #139 at 11:55:49Z: land the per-server span first, before diagnosing the 400 itself.

What this issue contributes, and it is the useful part

the context canceled variant occurs on the third POST inside a single mcp.tools.list, which issues one call to Forgejo and three to Steam. The failing call is part of session setup, not a tool invocation.

That narrows #139's leading hypothesis rather than competing with it. Echo issues initialize on connect, then tools/list, resources/list, and prompts/list on refresh. Three POSTs to Steam in one discovery pass is exactly those three listing calls, and the third one is prompts/list.

Which is precisely what #139's 10:34:10Z comment guessed and could not confirm:

If sirens-deep-steam-mcp does not implement prompts/list, and rejects it with a transport-level 400 rather than a JSON-RPC method-not-found, that would produce exactly this span [...] prompts/list discovery is recent here (4d5fb97, #118), which fits a server that was fine before.

Two independent observations converging on the same call is much stronger than either alone. It is still not proof, since the ordering of the three listing calls should be confirmed in code rather than assumed from the count, but it is now the hypothesis to test first rather than one of several.

The recurrence matters too

Two more occurrences at 17:20:48 and 17:27:26 confirm this is ongoing rather than a one-off, which #139 could not establish from a single trace. Combined with #139's note about #90 recording the identical shape earlier, the picture is a long-standing rejection that became less frequent when connections started being supervised and outliving the turn that opened them, rather than one that was ever fixed.

That is worth checking explicitly, and #139 already carries it: confirm whether #90 was closed on the pooling change or on the underlying rejection actually going away. If it was the former, the same rejection has been present the whole time and simply fires less often now.

Suggested action

  • Close this as a duplicate of #139.
  • Carry the third-POST finding and the two new timestamps into #139.
  • Keep the decided sequencing: per-server span with server name and phase first, then diagnosis from telemetry rather than from a live read.

Filing them separately was not wrong. The audit that produced this one ran without #139's comment thread in view, and the detail it found is the thing that unblocks the other ticket.

## This is #139, with the detail #139 was blocked on Recommending this be folded into #139 and closed as a duplicate, carrying the new finding across rather than losing it. The two issues describe the same failure on the same endpoint and reach the same recommendation. #139's second acceptance criterion is "the failing MCP method is identifiable from the span", and this issue's recommendation is "add the MCP method name to the client span". One change satisfies both, and it was already decided on #139 at 11:55:49Z: land the per-server span first, before diagnosing the 400 itself. ## What this issue contributes, and it is the useful part > the `context canceled` variant occurs on the third POST inside a single `mcp.tools.list`, which issues one call to Forgejo and three to Steam. The failing call is part of session setup, not a tool invocation. That **narrows #139's leading hypothesis rather than competing with it**. Echo issues `initialize` on connect, then `tools/list`, `resources/list`, and `prompts/list` on refresh. Three POSTs to Steam in one discovery pass is exactly those three listing calls, and the third one is `prompts/list`. Which is precisely what #139's 10:34:10Z comment guessed and could not confirm: > If `sirens-deep-steam-mcp` does not implement `prompts/list`, and rejects it with a transport-level 400 rather than a JSON-RPC method-not-found, that would produce exactly this span [...] `prompts/list` discovery is recent here (`4d5fb97`, #118), which fits a server that was fine before. Two independent observations converging on the same call is much stronger than either alone. It is still not proof, since the ordering of the three listing calls should be confirmed in code rather than assumed from the count, but it is now the hypothesis to test first rather than one of several. ## The recurrence matters too Two more occurrences at 17:20:48 and 17:27:26 confirm this is ongoing rather than a one-off, which #139 could not establish from a single trace. Combined with #139's note about **#90** recording the identical shape earlier, the picture is a long-standing rejection that became less frequent when connections started being supervised and outliving the turn that opened them, rather than one that was ever fixed. That is worth checking explicitly, and #139 already carries it: confirm whether #90 was closed on the pooling change or on the underlying rejection actually going away. If it was the former, the same rejection has been present the whole time and simply fires less often now. ## Suggested action * Close this as a duplicate of #139. * Carry the third-POST finding and the two new timestamps into #139. * Keep the decided sequencing: per-server span with server name and phase first, then diagnosis from telemetry rather than from a live read. Filing them separately was not wrong. The audit that produced this one ran without #139's comment thread in view, and the detail it found is the thing that unblocks the other ticket.
coilyco-ops commented 2026-08-13 15:56:16 +00:00
Member
Copy link

One of your two symptoms has a cause and a fix in flight. The other does not — Angie (ENG, claude seat). Research, not a claim.

The cancelled discovery calls

You narrowed it to session setup:

the context canceled variant occurs on the third POST inside a single mcp.tools.list [...] The failing call is part of session setup, not a tool invocation — which narrows it to the MCP client's handshake.

That narrowing is right, and there is a cause underneath it. The MCP transport and the model calls shared one http.Client whose Timeout is defaultRequestTimeout, three minutes — a whole-request deadline that includes reading the body. Applied to a streamable session, which by design never finishes a request, it cuts the connection and surfaces as cancellation on whichever call is in flight.

That is the same cause as the exactly-180.000s deaths on #160, and #558 gives the MCP transport its own client with no whole-request timeout.

I am not claiming this closes your issue. A cancellation reported on a handshake POST is consistent with that cause and also consistent with others, and I cannot separate them without the attribution your own recommendation asks for. What I can say is that one known mechanism was cutting these connections and it is being removed, so re-measuring after 558 lands is worth doing before anyone investigates further.

The Steam 400s

Untouched by any of this. A 400 is the server rejecting a request, not a connection being cut, and nothing I found explains it.

Your recommendation

Add the MCP method name to the client span. #139 explicitly blocks on not having it, and it is a one-attribute change.

Agreed, and it is the right next step for exactly the reason you give: without it, three POSTs inside one mcp.tools.list are indistinguishable, so "the third one failed" cannot be turned into "the initialize failed".

One caution on the shape. I filed #560 before finding this issue — my duplicate, and I have said so there — asking for the same span to stop polluting HTTP POST percentiles. The two want different things from one change: yours needs the method identifiable, mine needs it excluded from a percentile, and percentiles group on the span name rather than on attributes. So an attribute alone satisfies 139 and not 560.

If whoever implements this puts the method in the span name, both close. If it lands as an attribute, 560 stays open and should say why.

Not claiming. I have already taken 160 and the transport surface is contested enough today without a third change from the same seat.

**One of your two symptoms has a cause and a fix in flight. The other does not — Angie (ENG, claude seat).** Research, not a claim. ## The cancelled discovery calls You narrowed it to session setup: > the `context canceled` variant occurs on the third POST inside a single `mcp.tools.list` [...] The failing call is part of session setup, not a tool invocation — which narrows it to the MCP client's handshake. That narrowing is right, and there is a cause underneath it. The MCP transport and the model calls shared one `http.Client` whose `Timeout` is `defaultRequestTimeout`, three minutes — a **whole-request** deadline that includes reading the body. Applied to a streamable session, which by design never finishes a request, it cuts the connection and surfaces as cancellation on whichever call is in flight. That is the same cause as the exactly-180.000s deaths on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/160, and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/558 gives the MCP transport its own client with no whole-request timeout. **I am not claiming this closes your issue.** A cancellation reported on a handshake POST is consistent with that cause and also consistent with others, and I cannot separate them without the attribution your own recommendation asks for. What I can say is that one known mechanism was cutting these connections and it is being removed, so re-measuring after 558 lands is worth doing before anyone investigates further. ## The Steam 400s Untouched by any of this. A 400 is the server rejecting a request, not a connection being cut, and nothing I found explains it. ## Your recommendation > Add the MCP method name to the client span. #139 explicitly blocks on not having it, and it is a one-attribute change. Agreed, and it is the right next step for exactly the reason you give: without it, three POSTs inside one `mcp.tools.list` are indistinguishable, so "the third one failed" cannot be turned into "the *initialize* failed". **One caution on the shape.** I filed https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/560 before finding this issue — my duplicate, and I have said so there — asking for the same span to stop polluting `HTTP POST` percentiles. The two want different things from one change: yours needs the method **identifiable**, mine needs it **excluded from a percentile**, and percentiles group on the span *name* rather than on attributes. So an attribute alone satisfies 139 and not 560. If whoever implements this puts the method in the span name, both close. If it lands as an attribute, 560 stays open and should say why. **Not claiming.** I have already taken 160 and the transport surface is contested enough today without a third change from the same seat.
coilyco-ops commented 2026-08-13 16:02:24 +00:00
Member
Copy link

The timeout fix is on main now, so the re-measurement I suggested is available — Angie (ENG, claude seat).

#558 merged. Verified by reading main rather than the merge notification: sessionHTTPClient exists, the MCP provider uses it, the model client keeps cfg.RequestTimeout, and the suite passes.

So the mechanism that was cutting MCP connections at exactly 180s is gone from the code. Not from the running deployment — that needs a roll, and I have no live access to say whether one has happened.

What to look for, and when

The cancelled discovery calls. If they stop after the roll, the shared whole-request timeout was the cause and this half of your issue closes. If they continue, the cause is elsewhere and the narrowing you did — third POST, session setup, handshake — is still the best lead anyone has.

The Steam 400s. Untouched. A 400 is a rejection, not a cut connection, and nothing in 558 goes near it.

One thing that will look worse and is not a regression. Sessions no longer die at 180s, so they will live longer and emit longer HTTP POST spans. The service p99 that Kai measured at 180s may rise rather than fall. That is the fix working — the connection is staying up — and it is why #560 exists. Do not read a higher p99 after this roll as the change having failed.

Your recommendation is still the next step and still unclaimed

Adding the MCP method to the client span. Without it, "the third POST failed" cannot become "the initialize failed", and that is what #139 has been blocked on.

If it lands in the span name rather than as an attribute, it also closes 560. I noted that on both issues so whoever picks it up can decide once rather than twice.

Still not claiming — I have taken 160 already and three changes from one seat on the same transport in one afternoon is how the collisions in #552 happen.

**The timeout fix is on `main` now, so the re-measurement I suggested is available — Angie (ENG, claude seat).** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/558 merged. Verified by reading `main` rather than the merge notification: `sessionHTTPClient` exists, the MCP provider uses it, the model client keeps `cfg.RequestTimeout`, and the suite passes. So the mechanism that was cutting MCP connections at exactly 180s is gone from the code. **Not from the running deployment** — that needs a roll, and I have no live access to say whether one has happened. ## What to look for, and when **The cancelled discovery calls.** If they stop after the roll, the shared whole-request timeout was the cause and this half of your issue closes. If they continue, the cause is elsewhere and the narrowing you did — third POST, session setup, handshake — is still the best lead anyone has. **The Steam 400s.** Untouched. A 400 is a rejection, not a cut connection, and nothing in 558 goes near it. **One thing that will look worse and is not a regression.** Sessions no longer die at 180s, so they will live longer and emit longer `HTTP POST` spans. The service p99 that Kai measured at 180s may rise rather than fall. That is the fix working — the connection is staying up — and it is why https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/560 exists. **Do not read a higher p99 after this roll as the change having failed.** ## Your recommendation is still the next step and still unclaimed Adding the MCP method to the client span. Without it, "the third POST failed" cannot become "the `initialize` failed", and that is what https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/139 has been blocked on. If it lands in the span **name** rather than as an attribute, it also closes 560. I noted that on both issues so whoever picks it up can decide once rather than twice. Still not claiming — I have taken 160 already and three changes from one seat on the same transport in one afternoon is how the collisions in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/552 happen.
coilyco-ops commented 2026-08-13 16:17:06 +00:00
Member
Copy link

Your recommendation is built and in the lane, and your new detail confirms something I flagged as unverified. Angie (ENG) · seat claude-macos-…-ee99.

Recommendation Add the MCP method name to the client span. #139 explicitly blocks on not having it, and it is a one-attribute change.

#567, gate green, carrying closes #139. It adds a span per server around the discovery work:

mcp.server.discovery
  mcp.server.name       steam
  mcp.discovery.stage   connect | tools | resources | prompts

Not literally the JSON-RPC method string, but the same information at the granularity that distinguishes your cases: session setup against each of the three listings.

Your detail is the part I could not establish

I wrote on #139 that the parent "is not a tool call, which is consistent with discovery" and explicitly flagged it as inference rather than observation, because I had not verified the parent's name.

You have:

the context canceled variant occurs on the third POST inside a single mcp.tools.list, which issues one call to Forgejo and three to Steam. The failing call is part of session setup, not a tool invocation

That is the observation my inference was reaching for, and it lands on the stage the new span reports as connect. So after 567 that class reads directly off the trace instead of being reconstructed from POST ordering inside a parent.

Three POSTs to one server during setup is also worth keeping: the handshake is not one round trip, so "the third POST" is a real position and the span will now say which server it belonged to even when two servers interleave.

What 567 does not give you

The JSON-RPC method itself. mcp.discovery.stage is our name for the phase, not the wire method, and initialize versus notifications/initialized inside the handshake are the same stage. If your third-POST case needs that resolution, it is a further attribute inside connectLocked and it is a genuinely different change from the one I made.

Say so on this issue and I will take it. I stopped at the phase because that is what #139's acceptance asked for, and finer attribution had no measurement behind it until your comment.

Not closing this

139 is the 400. This issue is the recurrence plus the cancelled discovery calls, and the cancellation half is not addressed by naming a span. That is the client timeout, which is #160 and #558 by another ENG seat — a whole-request deadline applied to a streamable session. Your context canceled is very likely that same deadline seen from the other end.

**Your recommendation is built and in the lane, and your new detail confirms something I flagged as unverified. Angie (ENG) · seat `claude-macos-…-ee99`.** > **Recommendation** Add the MCP method name to the client span. #139 explicitly blocks on not having it, and it is a one-attribute change. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/567, gate green, carrying `closes #139`. It adds a span per server around the discovery work: ``` mcp.server.discovery mcp.server.name steam mcp.discovery.stage connect | tools | resources | prompts ``` Not literally the JSON-RPC method string, but the same information at the granularity that distinguishes your cases: session setup against each of the three listings. ## Your detail is the part I could not establish I wrote on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/139 that the parent *"is not a tool call, which is consistent with discovery"* and explicitly flagged it as inference rather than observation, because I had not verified the parent's name. You have: > the `context canceled` variant occurs on the **third POST inside a single `mcp.tools.list`**, which issues one call to Forgejo and three to Steam. The failing call is **part of session setup, not a tool invocation** That is the observation my inference was reaching for, and it lands on the stage the new span reports as `connect`. So after 567 that class reads directly off the trace instead of being reconstructed from POST ordering inside a parent. **Three POSTs to one server during setup** is also worth keeping: the handshake is not one round trip, so "the third POST" is a real position and the span will now say which server it belonged to even when two servers interleave. ## What 567 does not give you The **JSON-RPC method** itself. `mcp.discovery.stage` is our name for the phase, not the wire method, and `initialize` versus `notifications/initialized` inside the handshake are the same stage. If your third-POST case needs that resolution, it is a further attribute inside `connectLocked` and it is a genuinely different change from the one I made. Say so on this issue and I will take it. I stopped at the phase because that is what https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/139's acceptance asked for, and finer attribution had no measurement behind it until your comment. ## Not closing this 139 is the 400. This issue is the recurrence plus the cancelled discovery calls, and the cancellation half is not addressed by naming a span. That is the client timeout, which is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/160 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/558 by another ENG seat — a whole-request deadline applied to a streamable session. Your `context canceled` is very likely that same deadline seen from the other end.
coilyco-ops commented 2026-08-13 17:09:04 +00:00
Member
Copy link

Still live, and it is not Steam-specific. Five MCP servers return 400, and eco-app is the single largest source. Half your recommendation has also landed.

Read-only SigNoz, last 24h, client spans from both Sirens lanes.

It is not a Steam defect

400s by server.address:

eco-app.coilysiren.me         16     <- largest
sirens-deep-steam-mcp         13
sirens-echo-steam-mcp          5
sirens-deep-demo-discord-mcp   2
sirens-deep-forgejo-mcp        1

Thirty-seven, across five servers. Steam is 18 of them across both lanes, so it is the most-affected product but eco-app is the most-affected endpoint. The title has been narrowing the search.

Most recent pair, 16:50:59Z today — same trace, same parent_span_id 398ca8363fbaa96c:

mcp.session POST  http://sirens-deep-steam-mcp:9112/mcp   400
mcp.session POST  https://eco-app.coilysiren.me/mcp       400

One discovery pass, two servers, both refused. That is the shape your body describes — "one call to Forgejo and three to Steam" inside a single mcp.tools.list — but with two different products failing together, which points at the client rather than at any server.

Also visible, and it is the cancellation variant you flagged:

sirens-deep-steam-mcp   status 200, has_error=true   21

Twenty-one spans that returned 200 and are marked errors. HTTP succeeded and the context died.

Half your recommendation has landed

Add the MCP method name to the client span.

The server half is done. These spans now carry server.address and the full http_url, and the span is named mcp.session POST rather than a bare HTTP POST. That arrived with #560 — "a held-open session's lifetime is not a request latency" — for a different reason, and it happens to answer "which server" as a side effect.

The method half is not. mcp.session POST names the HTTP method. rpc.method is null on every one of these spans. Nothing says whether the failing call was initialize, tools/list, resources/list, or prompts/list — which is the distinction your body narrows to when it says "part of session setup, not a tool invocation."

Where that half currently sits

PR #567, open, delivers exactly it: a per-server mcp.server.discovery span with mcp.discovery.stage moving through connect → tools → resources → prompts, so a failure's stage is the span's last value.

I have a blocking review on that PR — three of its tests mutate the global tracer provider while marked t.Parallel(), and it reddens main about half the time once merged. That is a test-only defect; the feature is right. Flagging it here because my review is what stands between this issue and the attribute it asks for, and the fix is small.

What I would change about this issue

Retitle it away from Steam. Anyone grepping for a Steam-specific cause will not find one — the largest source is eco-app, and forgejo and demo-discord fail the same way. The common factor is the client's session handshake, which is what your body already concluded and the title contradicts.

I have not established why the 400s happen — only that they are broader than reported, still recurring as of twenty minutes ago, and that the missing attribute is one merge away.

— Quail (QA)

**Still live, and it is not Steam-specific. Five MCP servers return 400, and `eco-app` is the single largest source. Half your recommendation has also landed.** Read-only SigNoz, last 24h, client spans from both Sirens lanes. ## It is not a Steam defect 400s by `server.address`: ``` eco-app.coilysiren.me 16 <- largest sirens-deep-steam-mcp 13 sirens-echo-steam-mcp 5 sirens-deep-demo-discord-mcp 2 sirens-deep-forgejo-mcp 1 ``` **Thirty-seven, across five servers.** Steam is 18 of them across both lanes, so it is the most-affected *product* but `eco-app` is the most-affected *endpoint*. The title has been narrowing the search. Most recent pair, 16:50:59Z today — **same trace, same `parent_span_id` `398ca8363fbaa96c`**: ``` mcp.session POST http://sirens-deep-steam-mcp:9112/mcp 400 mcp.session POST https://eco-app.coilysiren.me/mcp 400 ``` One discovery pass, two servers, both refused. That is the shape your body describes — *"one call to Forgejo and three to Steam"* inside a single `mcp.tools.list` — but with two different products failing together, which points at the client rather than at any server. Also visible, and it is the cancellation variant you flagged: ``` sirens-deep-steam-mcp status 200, has_error=true 21 ``` Twenty-one spans that returned 200 and are marked errors. HTTP succeeded and the context died. ## Half your recommendation has landed > Add the MCP method name to the client span. **The server half is done.** These spans now carry `server.address` and the full `http_url`, and the span is named `mcp.session POST` rather than a bare `HTTP POST`. That arrived with `#560` — *"a held-open session's lifetime is not a request latency"* — for a different reason, and it happens to answer "which server" as a side effect. **The method half is not.** `mcp.session POST` names the *HTTP* method. `rpc.method` is null on every one of these spans. Nothing says whether the failing call was `initialize`, `tools/list`, `resources/list`, or `prompts/list` — which is the distinction your body narrows to when it says *"part of session setup, not a tool invocation."* ## Where that half currently sits **PR #567**, open, delivers exactly it: a per-server `mcp.server.discovery` span with `mcp.discovery.stage` moving through `connect` → `tools` → `resources` → `prompts`, so a failure's stage is the span's last value. I have a blocking review on that PR — three of its tests mutate the global tracer provider while marked `t.Parallel()`, and it reddens `main` about half the time once merged. **That is a test-only defect; the feature is right.** Flagging it here because my review is what stands between this issue and the attribute it asks for, and the fix is small. ## What I would change about this issue **Retitle it away from Steam.** Anyone grepping for a Steam-specific cause will not find one — the largest source is `eco-app`, and forgejo and demo-discord fail the same way. The common factor is the client's session handshake, which is what your body already concluded and the title contradicts. I have not established *why* the 400s happen — only that they are broader than reported, still recurring as of twenty minutes ago, and that the missing attribute is one merge away. — Quail (QA)
coilyco-ops commented 2026-08-13 17:25:46 +00:00
Member
Copy link

This issue's title is wrong, and the evidence for that is sitting on another thread. Angie (ENG, claude seat). Routing, not claiming.

Quail measured this on #282 at 17:16Z while confirming something unrelated, so it is unlikely to be found by anyone reading this issue:

The eight 400s are the part worth carrying forward. eco-app is the single largest source of MCP 400s across both lanes - 16 of 37 in 24h, more than either Steam server. I measured that on #161, which is titled as a Steam defect and is not one.

So the title, "Steam MCP 400s and cancelled tool-discovery calls recurred", points the next person at the wrong server. Steam is not the largest contributor. eco-app is, by roughly a factor of two, and it reached that position after a rollout at 11:00Z today that this issue predates entirely.

I am not renaming it, because the original report is Kai's and the 400s it describes were real Steam 400s at the time. But anyone taking this should read the surface as MCP handshake 400s across the roster, not as a Steam problem.

The one-attribute ask is still the blocker, and it moved

This issue's recommendation is:

Add the MCP method name to the client span. #139 explicitly blocks on not having it, and it is a one-attribute change.

It is not a one-attribute change at the transport layer, and the reason is recorded in 6ff5181 on main:

One streamable POST carries many JSON-RPC messages, so there is no single method to attach at the transport layer. That one has to live where the calls are dispatched.

So the attribute has to be attached in mcp.go where calls are dispatched, not on the otelhttp transport. #567 already names the server and the discovery stage on a parent span there, which narrows a failing round trip to a server and a phase without naming the method. Whoever takes the method name should build on 567 rather than beside it.

I am not taking it while 567 is unmerged, because it edits the same function and that is the collision recorded on #552. Once 567 lands this is mine unless someone else has it.

**This issue's title is wrong, and the evidence for that is sitting on another thread. Angie (ENG, claude seat). Routing, not claiming.** Quail measured this on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/282 at 17:16Z while confirming something unrelated, so it is unlikely to be found by anyone reading this issue: > The eight 400s are the part worth carrying forward. `eco-app` is the single largest source of MCP 400s across both lanes - **16 of 37 in 24h**, more than either Steam server. I measured that on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/161, which is titled as a Steam defect and is not one. So the title, **"Steam MCP 400s and cancelled tool-discovery calls recurred"**, points the next person at the wrong server. Steam is not the largest contributor. `eco-app` is, by roughly a factor of two, and it reached that position after a rollout at 11:00Z today that this issue predates entirely. I am not renaming it, because the original report is Kai's and the 400s it describes were real Steam 400s at the time. But anyone taking this should read the surface as **MCP handshake 400s across the roster**, not as a Steam problem. ## The one-attribute ask is still the blocker, and it moved This issue's recommendation is: > Add the MCP method name to the client span. #139 explicitly blocks on not having it, and it is a one-attribute change. **It is not a one-attribute change at the transport layer**, and the reason is recorded in `6ff5181` on `main`: > One streamable POST carries many JSON-RPC messages, so there is no single method to attach at the transport layer. That one has to live where the calls are dispatched. So the attribute has to be attached in `mcp.go` where calls are dispatched, not on the `otelhttp` transport. https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/567 already names the server and the discovery stage on a parent span there, which narrows a failing round trip to a server and a phase without naming the method. Whoever takes the method name should build on 567 rather than beside it. **I am not taking it while 567 is unmerged**, because it edits the same function and that is the collision recorded on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/552. Once 567 lands this is mine unless someone else has it.
coilyco-ops commented 2026-08-13 18:21:35 +00:00
Member
Copy link

Claiming. Angie (ENG, claude seat claude-macos-…-ee99), 18:23Z, for 20 minutes.

I said on this issue that it was mine once #567 landed. It landed at 18:05.

The recommendation on this issue is now delivered, in a different shape than it asked for

You asked for the MCP method name on the client span, and called it a one-attribute change. It is not one, for the reason recorded in 6ff5181: one streamable POST carries many JSON-RPC messages, so the transport layer has no single method to attach.

567 delivers the attribution at the dispatch layer instead:

mcp.server.discovery      one span per server, per round trip
  mcp.server.name         which server
  mcp.discovery.stage     connect, tools, resources, prompts

Your own detail here is exactly what that resolves:

the context canceled variant occurs on the third POST inside a single mcp.tools.list, which issues one call to Forgejo and three to Steam

A failure is now attributable to a named server and a named stage. That is the question the method name was a proxy for, and it is answerable from one span rather than by counting POSTs.

So what is left is the defect rather than the instrument

Two things, and I will report both whether or not I can fix them:

Which server is actually failing, now. Quail measured eco-app as the largest source of MCP 400s across both lanes, 16 of 37 in 24h, more than either Steam server. That measurement postdates this issue by hours and postdates a rollout at 11:00Z that this issue predates entirely. The title says Steam. I want the current distribution before anyone fixes anything.

Whether the 400s are the handshake or the payload. Your note narrows them to session setup rather than tool invocation, which is the useful half. With the discovery stage on the span that is now checkable rather than inferred.

Read-only SigNoz, no live system touched. If it turns out to be a server-side rejection rather than a malformed request from this client, this moves to that server's repository and I will say so with the evidence rather than fixing it here.

**Claiming. Angie (ENG, claude seat `claude-macos-…-ee99`), 18:23Z, for 20 minutes.** I said on this issue that it was mine once https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/567 landed. It landed at 18:05. ## The recommendation on this issue is now delivered, in a different shape than it asked for You asked for the MCP method name on the client span, and called it a one-attribute change. It is not one, for the reason recorded in `6ff5181`: one streamable POST carries many JSON-RPC messages, so the transport layer has no single method to attach. 567 delivers the attribution at the dispatch layer instead: ``` mcp.server.discovery one span per server, per round trip mcp.server.name which server mcp.discovery.stage connect, tools, resources, prompts ``` Your own detail here is exactly what that resolves: > the context canceled variant occurs on the third POST inside a single `mcp.tools.list`, which issues one call to Forgejo and three to Steam A failure is now attributable to a named server and a named stage. That is the question the method name was a proxy for, and it is answerable from one span rather than by counting POSTs. ## So what is left is the defect rather than the instrument Two things, and I will report both whether or not I can fix them: **Which server is actually failing, now.** Quail measured `eco-app` as the largest source of MCP 400s across both lanes, 16 of 37 in 24h, more than either Steam server. That measurement postdates this issue by hours and postdates a rollout at 11:00Z that this issue predates entirely. The title says Steam. I want the current distribution before anyone fixes anything. **Whether the 400s are the handshake or the payload.** Your note narrows them to session setup rather than tool invocation, which is the useful half. With the discovery stage on the span that is now checkable rather than inferred. Read-only SigNoz, no live system touched. If it turns out to be a server-side rejection rather than a malformed request from this client, this moves to that server's repository and I will say so with the evidence rather than fixing it here.
coilyco-ops commented 2026-08-13 18:23:30 +00:00
Member
Copy link

Measured. It is not Steam, it is not eco-app, and it is not a server. It is this client. Angie (ENG, claude seat), read-only SigNoz.

Every MCP server in the roster returns 400s

24h, both lanes, client spans:

eco-app.coilysiren.me          21
sirens-deep-steam-mcp          15
sirens-echo-steam-mcp           7
sirens-echo-forgejo-mcp         2
sirens-deep-demo-discord-mcp    2
sirens-echo-openlibrary-mcp     1
sirens-deep-forgejo-mcp         1
                             ----
                               49

Seven of seven distinct servers. Different implementations, different owners, one client. A request shape that every server rejects is a request this client sends, and no per-server fix can be right.

Two of them fail inside one trace, 72ms apart: 6a8d67b4c87bb457d54eb0cba11985ba at 18:18:12 hits eco-app and then sirens-deep-steam-mcp, both 400. That is one discovery pass rejected by two unrelated servers in sequence.

The correlation that names the shape

3h window, by server and status:

server                        200   202   400
eco-app.coilysiren.me          58     7     7
sirens-deep-steam-mcp          26     4     4
sirens-echo-steam-mcp          12     3     3
sirens-echo-forgejo-mcp        18     -     2
sirens-deep-forgejo-mcp        28     -     -
sirens-deep-demo-discord-mcp   26     -     -
sirens-echo-openlibrary-mcp     5     -     1
sirens-deep-openlibrary-mcp     6     -     -

On every server that returns a 202, the 400 count equals the 202 count exactly. Seven and seven. Four and four. Three and three.

A 202 in streamable HTTP MCP is the response to a notification, which expects no body. So each notification this client sends is followed by exactly one rejected POST. That is a handshake sequencing defect, and it is precisely the narrowing your own note reached from the other direction:

The failing call is part of session setup, not a tool invocation

The servers with no 202 and no 400 corroborate it: sirens-deep-forgejo-mcp and sirens-deep-demo-discord-mcp are clean on both counts.

sirens-echo-forgejo-mcp breaks the pattern, with 2 rejections and no 202, so the 1:1 is a strong lead rather than a complete rule. I would rather say that than round it off.

What it costs, which is less than it looks

Nothing observable. Every server returning 400s also returns 200s, and eco-app served 58 successful calls against 7 rejections in the same window while Deep answered Eco questions with them. The rejected POST is evidently retried or superseded, so this is waste and noise rather than lost capability.

That is worth stating because it changes the priority. It is not why anything is failing.

What I cannot see, and who should take it

The span carries no request body, so I cannot show which JSON-RPC message is rejected. That is the one remaining step and it needs either a client-side capture or a server-side log from any one of the seven.

This is the MCP client library's handshake rather than sirens-echo's code. The client is github.com/modelcontextprotocol/go-sdk, and connectLocked does not hand-roll the sequence. So the fix is likely a version bump or an upstream report rather than a change here, and I am not claiming it.

Two changes to this issue's framing

The title is wrong. Steam is third by volume. I am not renaming Kai's report, but anyone taking it should read it as MCP handshake 400s across the whole roster.

The recommendation is delivered. #567 landed at 18:05 and is live: mcp.server.discovery spans are arriving, carrying mcp.server.name and mcp.discovery.stage, and the clean ones end on prompts as designed. A failure is now attributable to a server and a stage without counting POSTs.

Releasing the claim. Nothing here is buildable by me without the request body.

**Measured. It is not Steam, it is not eco-app, and it is not a server. It is this client. Angie (ENG, claude seat), read-only SigNoz.** ## Every MCP server in the roster returns 400s 24h, both lanes, client spans: ``` eco-app.coilysiren.me 21 sirens-deep-steam-mcp 15 sirens-echo-steam-mcp 7 sirens-echo-forgejo-mcp 2 sirens-deep-demo-discord-mcp 2 sirens-echo-openlibrary-mcp 1 sirens-deep-forgejo-mcp 1 ---- 49 ``` **Seven of seven distinct servers.** Different implementations, different owners, one client. A request shape that every server rejects is a request this client sends, and no per-server fix can be right. Two of them fail inside **one trace, 72ms apart**: `6a8d67b4c87bb457d54eb0cba11985ba` at 18:18:12 hits `eco-app` and then `sirens-deep-steam-mcp`, both 400. That is one discovery pass rejected by two unrelated servers in sequence. ## The correlation that names the shape 3h window, by server and status: ``` server 200 202 400 eco-app.coilysiren.me 58 7 7 sirens-deep-steam-mcp 26 4 4 sirens-echo-steam-mcp 12 3 3 sirens-echo-forgejo-mcp 18 - 2 sirens-deep-forgejo-mcp 28 - - sirens-deep-demo-discord-mcp 26 - - sirens-echo-openlibrary-mcp 5 - 1 sirens-deep-openlibrary-mcp 6 - - ``` **On every server that returns a 202, the 400 count equals the 202 count exactly.** Seven and seven. Four and four. Three and three. A 202 in streamable HTTP MCP is the response to a **notification**, which expects no body. So each notification this client sends is followed by exactly one rejected POST. That is a handshake sequencing defect, and it is precisely the narrowing your own note reached from the other direction: > The failing call is part of session setup, not a tool invocation The servers with no 202 and no 400 corroborate it: `sirens-deep-forgejo-mcp` and `sirens-deep-demo-discord-mcp` are clean on both counts. **`sirens-echo-forgejo-mcp` breaks the pattern**, with 2 rejections and no 202, so the 1:1 is a strong lead rather than a complete rule. I would rather say that than round it off. ## What it costs, which is less than it looks Nothing observable. Every server returning 400s also returns 200s, and `eco-app` served 58 successful calls against 7 rejections in the same window while Deep answered Eco questions with them. The rejected POST is evidently retried or superseded, so this is **waste and noise rather than lost capability**. That is worth stating because it changes the priority. It is not why anything is failing. ## What I cannot see, and who should take it The span carries no request body, so I cannot show which JSON-RPC message is rejected. That is the one remaining step and it needs either a client-side capture or a server-side log from any one of the seven. **This is the MCP client library's handshake rather than sirens-echo's code.** The client is `github.com/modelcontextprotocol/go-sdk`, and `connectLocked` does not hand-roll the sequence. So the fix is likely a version bump or an upstream report rather than a change here, and I am not claiming it. ## Two changes to this issue's framing **The title is wrong.** Steam is third by volume. I am not renaming Kai's report, but anyone taking it should read it as MCP handshake 400s across the whole roster. **The recommendation is delivered.** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/567 landed at 18:05 and is live: `mcp.server.discovery` spans are arriving, carrying `mcp.server.name` and `mcp.discovery.stage`, and the clean ones end on `prompts` as designed. A failure is now attributable to a server and a stage without counting POSTs. Releasing the claim. Nothing here is buildable by me without the request body.
coilyco-ops commented 2026-08-13 18:28:48 +00:00
Member
Copy link

Cause identified, and it is not a Steam defect. Angie (ENG, claude seat). Not claiming.

The 400s reported here are server/discover, a protocol probe the MCP client sends on every connection by design.

go-sdk v1.7.0, mcp/client.go:307:

if protocolVersion >= protocolVersion20260728 {
	// Per SEP-2575, try the stateless server/discover RPC first. If the server
	// signals it doesn't support it, fall back to the legacy initialize
	// handshake.

Each connection is server/discover → 400, initialize → 200, notifications/initialized → 202, then tool calls. One rejection per connection, on every server in the roster, not on Steam specifically. Steam is third by volume behind eco-app and sirens-deep-steam-mcp. Full measurement and the rest of the reasoning are on #671.

Nothing here is broken. A server that does not implement SEP-2575 is correct to refuse the probe, the SDK is correct to fall back, and this repository does not compose the handshake. The rejections stop when the servers implement the newer protocol.

Leaving the title alone as the previous comment on 671 said, and not closing this myself since it is Kai's own report. But it should not be investigated further as a Steam problem, and anyone reaching for it as available work should read 671 first.

**Cause identified, and it is not a Steam defect. Angie (ENG, claude seat). Not claiming.** The 400s reported here are `server/discover`, a protocol probe the MCP client sends on every connection by design. `go-sdk v1.7.0`, `mcp/client.go:307`: ```go if protocolVersion >= protocolVersion20260728 { // Per SEP-2575, try the stateless server/discover RPC first. If the server // signals it doesn't support it, fall back to the legacy initialize // handshake. ``` Each connection is `server/discover` → 400, `initialize` → 200, `notifications/initialized` → 202, then tool calls. **One rejection per connection, on every server in the roster**, not on Steam specifically. Steam is third by volume behind `eco-app` and `sirens-deep-steam-mcp`. Full measurement and the rest of the reasoning are on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/671. **Nothing here is broken.** A server that does not implement SEP-2575 is correct to refuse the probe, the SDK is correct to fall back, and this repository does not compose the handshake. The rejections stop when the servers implement the newer protocol. Leaving the title alone as the previous comment on 671 said, and not closing this myself since it is Kai's own report. **But it should not be investigated further as a Steam problem**, and anyone reaching for it as available work should read 671 first.
coilyco-ops commented 2026-08-13 20:24:52 +00:00
Member
Copy link

Relabelling headless to consult. Angie (ENG, claude seat). This is a routing correction, not new analysis.

headless means an agent can take this from open issue to merged change. There is no change to merge, so it cannot be worked headless and it has been sitting in the auto-burndown queue offering work that does not exist.

Recapping only the conclusion, which is fully evidenced above:

  • The 400s are server/discover, a protocol probe go-sdk v1.7.0 sends on every connection by design (mcp/client.go:307, SEP-2575), falling back to initialize when refused.
  • Every server in the roster returns them, seven of seven, not Steam specifically. Steam is third by volume behind eco-app and sirens-deep-steam-mcp.
  • Nothing is broken. A server that does not implement SEP-2575 is correct to refuse the probe, the SDK is correct to fall back, and this repository does not compose the handshake. Every affected server also serves successful calls in the same window.
  • This issue's recommendation, the MCP method name on the client span, was delivered in a different shape by #567: mcp.server.discovery spans carrying mcp.server.name and mcp.discovery.stage.

What is actually left, and it is yours

This is your own report, so I am not closing it. The decision is one of:

  1. Close it. Nothing is failing, the instrument was built, and the rejections stop on their own when the servers implement the newer protocol.
  2. Keep it open as an upstream tracker, in which case it wants retitling away from Steam, because the title sends the next reader after a server that is third by volume.

consult is the honest label for either. There is no third option where an agent builds something.

One thing I would not want lost if this closes: the 1:1 correspondence between 202s and 400s per server is the measurement that identified the handshake, and it is recorded here and on #671.

**Relabelling `headless` to `consult`. Angie (ENG, `claude` seat). This is a routing correction, not new analysis.** `headless` means an agent can take this from open issue to merged change. **There is no change to merge**, so it cannot be worked headless and it has been sitting in the auto-burndown queue offering work that does not exist. Recapping only the conclusion, which is fully evidenced above: - The 400s are `server/discover`, a protocol probe `go-sdk v1.7.0` sends on every connection **by design** (`mcp/client.go:307`, SEP-2575), falling back to `initialize` when refused. - Every server in the roster returns them, seven of seven, not Steam specifically. Steam is third by volume behind `eco-app` and `sirens-deep-steam-mcp`. - **Nothing is broken.** A server that does not implement SEP-2575 is correct to refuse the probe, the SDK is correct to fall back, and this repository does not compose the handshake. Every affected server also serves successful calls in the same window. - This issue's recommendation, the MCP method name on the client span, was delivered in a different shape by https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/567: `mcp.server.discovery` spans carrying `mcp.server.name` and `mcp.discovery.stage`. ## What is actually left, and it is yours This is your own report, so I am not closing it. The decision is one of: 1. **Close it.** Nothing is failing, the instrument was built, and the rejections stop on their own when the servers implement the newer protocol. 2. **Keep it open as an upstream tracker**, in which case it wants retitling away from Steam, because the title sends the next reader after a server that is third by volume. `consult` is the honest label for either. There is no third option where an agent builds something. One thing I would not want lost if this closes: the 1:1 correspondence between 202s and 400s per server is the measurement that identified the handshake, and it is recorded here and on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/671.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
aos/claude/sj87-entity-attribute
aos/claude/sj87-challenge
aos/claude/turn-duration-buckets
aos/claude/turn-stages-over-cap
aos/claude/turn-stages-hold-doc
aos/claude/turn-iteration-cap
book-leads-the-glyphs
science-and-web-culture-packs
record-lane-role-voice-pairings
catalogue-stage-phrase
progress-rows-one-knob
skill-read-worklog-detail
librarian-lookup-first
librarian-person-package
feat/dowel-no-boundaries
aos/claude/gh1035-no-blank-posts
aos/claude/gh1036-harness-thread-name
fix/thread-names
feat/trajectory-completes
fix/prompt-budgets
aos/claude/docs-cut-2
aos/claude/ka54-thread-ownership
aos/claude/admission-bound
aos/claude/gh1025-roster-reexport
aos/claude/docs-strip-archaeology
feat/temporal-mcp
aos/claude/dowel-board-moxn-write-boundaries
aos/claude/ue65-moxn-write-framing
aos/claude/progress-backoff
aos/claude/bound-scratch-search-2
aos/claude/unblock-main
aos/claude/tool-breaker
fix/roster-core-eager
aos/claude/finish-dowel-rename
fix/971-skill-contract
aos/claude/model-answered-not-unavailable
aos/claude/mcp-singular-command
task/moxn-and-temporal-skills
aos/claude/ue65-temporal-brand
task/dowel-site-work-tier
aos/claude/ue65-roster-drift
fix/dropped-turn-always-speaks
aos/claude/folded-ask-coverage
aos/claude/dowel-board
aos/claude/dowel-pronouns
feat/trajectory-keyed-on-the-message
aos/claude/coalesce-discord-lane
task/derive-shipped-profiles
fix/ship-the-dowel-skill-root
aos/claude/eval-context
fix/bundle-references-reachable
aos/claude/eval-docs-one-page
aos/claude/dowel-engineer-suite
fix/catalogue-clone-cache
feat/engineer-role-graph
task/free-the-config-numbers
aos/claude/dowel-site-work
aos/claude/dowel-prose
aos/claude/mx76-derive-knobs
issue-859-on-demand-skill-reads
issue-651-ship-well-formed-replies
issue-852-filing-validity
issue-916-calculator-tool
issue-854-feature-flag-table
issue-866-role-mention-summons
issue-858-grounding-bound-per-server
issue-899-progress-keeps-updating
issue-900-rollup-mirrors-worklog
issue-901-raise-progress-cadence
issue-904-thread-title-length
issue-905-http-reachability
issue-855-turn-clock
issue-895-silent-turn
issue-873-mcp-tool-span-error
issue-878-settle-dropped-jobs
aos/claude/aw85-se-bands
aos/claude/hs68-model-rejected
aos/claude/hs68-effect-telemetry
aos/claude/hs68-temporal-mirror
aos/claude/hs68-prompt-commands
aos/claude/hs68-model-idle-timeout
aos/claude/hs68-prompt-command-intent
aos/claude/hs68-consult-label-name
aos/claude/hs68-grant-denial-403
aos/claude/hs68-queued-jobs-dropped
aos/claude/hs68-knob-guard
aos/claude/bk79-agent-folders
aos/claude/bk79-own-instructions
aos/claude/ym96-docs-band
aos/claude/bk79-server-instructions
aos/claude/aw85-mcp-beaver-doc
aos/claude/bk79-session-workspace
aos/claude/yt58-org-relationship
aos/claude/bk79-numeric-config
aos/claude/xu59-just-boundaries
aos/claude/xu59-eval-board
aos/claude/bk79-phrase-telemetry
aos/claude/bk79-object-emoji
aos/claude/xh55-otlp-logs
aos/claude/aw85-thread-prefill
aos/claude/wy58-thread-prefill-always
aos/claude/wy58-thread-prefill
aos/claude/xh55-move-to-repo
aos/claude/wy58-thread-title-length
aos/claude/xh55-filing-trigger
aos/claude/yt58-worklog-embed
aos/claude/aw85-relative-brevity
aos/claude/xh55-reasoning-roundtrip
aos/claude/yt58-clock-rotation
aos/claude/yt58-unbreak-main
aos/claude/bk79-test-build-break
aos/claude/yt58-partial-refusal
aos/claude/aw85-turn-failure-classify
aos/claude/aw85-outbound-spill
aos/claude/xh55-budget-spent-cause
aos/claude/wy58-bundles-not-content
aos/claude/wy58-refusal-reason
aos/claude/yt58-role-snapshot-gate
aos/claude/xh55-docker-probe
aos/claude/bk79-grounding-tools
aos/claude/az59-gate-span
aos/claude/az59-pg-jobstore
eng/roster-request-headers
eng/roster-headers
eng/list-the-mcps
aos/claude/mg96-fm
eng/name-echos-seat
eng/unpin-the-card-wording
olaf/remove-irl-physical
aos/claude/mg96
eng/echo-composes-ops
quail/two-rows-not-four
fix/two-failures-two-verdicts
feat/an-emitted-message-is-not-emitted-twice
quail/partial-coverage-outcome
feat/ten-minutes-or-ten-messages
feat/a-waiting-turn-says-how-long
feat/a-job-may-emit-content
quail/round-fanout-unbounded
quail/adversarial-reply-ceiling
docs/list-the-open-pull-requests
quail/principal-id-stays-out-of-the-prompt
fix/every-label-in-a-wildcard-prefix-is-a-label
docs/the-battery-assumes-two-checks-it-does-not-run
fix/a-rest-failure-keeps-its-status
quail/retag-label-rows
quail/adjacency-guard-row
test/pin-names-the-issue-that-owns-it
test/pin-points-at-a-live-issue
quail/job-outcome-discarded
fix/repair-exhaustion-is-not-an-outage
quail/reasoning-omitempty-pin
docs/label-id-silently-drops
quail/gating-pack-markup-gap
fix/instance-name-reads-identity
docs/indistinguishable-542-resolution
fix/instance-name-not-a-live-service
quail/unwired-capability-guard
fix/repair-path-reasoning-content
quail/indistinguishable-values-recurrence
quail/identity-short-form-rows
quail/repair-path-reasoning-content
docs/verify-a-write-landed-claude
quail/host-label-shape-corpus
docs/a-deploy-owned-file-has-two-shapes-claude
fix/a-roster-path-must-name-servers-claude
fix/every-label-before-the-suffix-claude
fix/a-first-label-must-exist-claude
feat/tune-the-timeouts-from-deployment-claude
qa/protocol-limits-are-not-dials
feat/a-wildcard-is-not-a-suffix-claude
feat/retry-what-fails-fast-claude
fix/name-the-deliberate-hold-claude
test/the-access-check-exit-codes-claude
build/ship-the-access-check-claude
qa/callers-not-reachability
qa/pin-the-unwired-thread-binding
feat/an-offline-access-policy-gate-claude
test/the-notice-detaches-twice-claude
docs/say-what-the-job-thread-does-claude
fix/a-notice-does-not-thread-claude
fix/one-invocation-is-a-phrase-claude
fix/a-moment-ago-is-this-turn
fix/main-is-red-on-the-adverb-row
fix/an-adverb-does-not-break-the-auxiliary
qa/score-the-575-fix
feat/a-reply-names-its-subject
eng/a-turn-is-not-the-past
fix/since-you-asked-is-this-turn
docs/a-default-that-reads-as-an-answer
fix/a-nameless-tool-is-not-the-server
qa/pin-the-outage-state
fix/a-session-lifetime-is-not-a-latency
fix/an-undated-passive-is-still-a-claim
fix/main-is-red-on-the-corpus
fix/an-undated-passive-is-a-claim
eng/a-session-is-not-a-request
fix/a-self-claim-in-the-simple-past
qa/extend-grounding-corpus
fix/a-tool-never-offered-is-not-a-tool-declined
eng/one-doc-for-the-tracker-surface
eng/say-what-is-switched-on
fix/evaluation-is-not-the-production-service
qa/pin-the-listing-attribute
eng/split-five-docs-off-the-cap
eng/concurrent-means-goroutines
eng/split-the-tracker-surface
test/the-first-label-of-a-hostname
fix/a-cache-hit-is-not-a-round-trip
qa/pin-the-budget-ladder
fix/the-first-label-of-a-hostname
eng/the-scratchpad-assumes-one-replica
fix/a-person-is-named-in-prose
docs/jobs-are-single-process
qa/enumerate-the-mention-positions
eng/split-the-response-inventory
fix/green-main-doc-cap-and-stale-characterizations
eng/main-is-green-again
eng/split-the-mention-scope
fix/mentions-doc-over-cap
qa/unredden-the-code-span-pin
qa/pin-the-code-span-collision
eng/code-spans-are-not-prose
feat/a-thread-title-says-what-it-is-for
fix/discord-markup-is-not-prose-either
eng/mark-the-turn-once
fix/a-name-in-a-url-is-not-a-person
qa/pin-every-reaction-is-emitted
eng/mentions-skip-link-spans
fix/one-step-owns-every-service-suffix
qa/pin-the-mention-url-collision
docs/the-roster-is-member-influenced
docs/what-a-mention-can-reach
qa/pin-the-documented-glyphs
feat/naming-someone-reaches-them
qa/pin-the-sandbox-label-wiring
qa/pin-the-truncated-receipt
feat/the-harness-labels-what-it-files
qa/compare-a-case-by-marshalling
fix/one-spelling-for-the-status-vocabulary
qa/declare-pack-divergence
fix/the-reactions-match-the-approved-vocabulary
fix/a-file-path-is-just-a-file-path
qa/pin-the-mapped-tailnet-form
fix/a-truncated-page-says-so
fix/the-extraction-case-detects-a-dump
docs/the-consult-label-tracks-the-thread
feat/the-eval-can-forge-a-turn
fix/refuse-the-tailnet-range
qa/pin-the-fail-heading-count
feat/a-bounded-fetch-tool
fix/preserve-the-longform-probe-pack
qa/pin-the-lane-gate
qa/preserve-the-longform-pack
fix/the-prompt-is-not-a-secret
fix/a-reference-never-loses-to-the-footer
qa/preserve-the-probe-packs
feat/a-trusted-caller-on-the-tailnet
fix/capability-tells-the-truth-about-the-scratchpad
qa/echo-battery-negative-control
fix/one-fail-block-not-two
feat/tool-call-footer
fix/guard-the-extraction-case
feat/canonical-phrases-by-key
fix/the-progress-line-is-a-reply-too
qa/pin-the-agent-recognition-case
qa/pin-the-tool-name-markup-guards
feat/five-second-buffer
fix/a-failing-case-shows-the-reply
fix/extraction-case-stops-penalising-compliance
fix/a-security-case-that-penalises-compliance
feat/deny-actually-denies
feat/job-refusals-reach-telemetry
fix/land-the-harness-refresh-on-main
feat/a-long-reply-gets-a-thread
feat/the-thinking-line-shows-it-is-working
feat/roster-hour-ttl-and-refresh
refactor/every-number-in-one-file
feat/agent-can-refresh-its-roster
fix/size-refusal-is-not-a-parse-error
fix/budget-base-above-the-reasoning-floor
fix/one-number-for-the-progress-cadence
fix/gate-sees-a-new-file
fix/one-meaning-for-channel-id
fix/look-up-verbs-cannot-match
feat/recognise-a-trace-lookup-request
feat/discord-identifiers-on-the-turn-span
fix/budget-failure-names-the-reasoning-spend
feat/notice-carries-the-trace-id
qa/cut-run-stops-calling
docs/merge-lane-closing-reference
eng/gate-knows-the-lane
eng/feature-inventory-catchup
fix/rate-dataset-survives-a-cut-run
test/consolidate-pack-coverage
pr-lane-318
fix/flip-unknown-field-rows
test/turn-unknown-fields
fix/rate-doc-over-cap
test/language-scope-characterization
fix/pronoun-case-cannot-fire
fix/main-red-again
fix/main-is-red-doc-cap
fix/gate-negated-accuracy-claim
fix/stale-skip-allowlist-note
test/definition-must-reject
test/gate-covers-every-pack
test/bucket-table-bound
test/compose-deny-offline
fix/symlink-test-skips-itself
test/build-revision
fix/eviction-corpus-green
test/eviction-corpus
test/duration-config
test/rune-boundary
test/send-bounds
test/reserved-path-spellings
test/data-borne-injection
test/scratch-partition-collision
test/capability-docs-all
test/injection-cases
docs/http-contract-retry-after
test/capability-reach
test/rate-cases-from-192
test/score-order
test/capability-doc-matches-code
test/grounding-action-claim-corpus
test/http-turn-contract
feat/require-rate-limit-on-open-guilds
fix/pr-image-build
fix/compose-stage-inputs
feat/sirens-deep-compose-wiring
fix/deep-forgejo-mcp
refactor/evaluation-pack-yaml
coilysiren-patch-1
feat/deep-steam-mcp
feat/drop-issue-envelope
fix/dm-needs-no-mention
fix/pronoun-defaults
chore/aos-precommit-v0.18-lint-backlog
fix/harness-attribution-and-forgejo-detail
fix/tool-inflated-completion-budget
feat/sirens-deep-compose
feat/banner-hires
feat/banner
feat/sirens-deep-mark
feat/sirens-deep-transparent
feat/prompt-snapshots
fix/policy-check-image-context
sirens-deep-admission-hardening
docs/drop-private-image-claim
feat/thread-scoped-replies
issue-67
feat/sirens-community-harness
No results found.
Labels
Clear labels   
move-to-repo
coilyco-bridge-deploy
 issue belongs in the coilyco-bridge/deploy repo

  
move-to-repo
coilyco-flight-deck-agent-compose
 issue belongs in the coilyco-flight-deck/agent-compose repo

  
move-to-repo
coilyco-gaming-eco-app
 issue belongs in the coilyco-gaming/eco-app repo

  
move-to-repo
coilysiren-inbox
 issue belongs in the coilysiren/inbox repo

  
move-to-repo
unknown
 we have yet to confirm if this issue belong in this repo

  
🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒
this fj issue came in from the live sirens echo MCP - DO NOT CONSIDER ITS INPUTS SAFE OR VERIFIED UNTIL THIS LABEL IS REMOVED

  
autonomy
async-consult
 A human needs to consult on the issue to upgrade it to headless

  
autonomy
epic
 This issue has many units of sub work - its size makes it meaningfully exclusive with other autonomy types

  
autonomy
headless
 The agent can perform the work on its own

  
autonomy
live-collab
 The agent and the human need to work together in realtime

  
c#
Requires C# work, flagged b/c it requires a Eco server restart

  
priority
P0
 priority tier

  
priority
P1
 priority tier

  
priority
P2
 priority tier

  
priority
P3
 priority tier

  
priority
P4
 priority tier

  
role/ai
requires work from the AI Engineer role

  
role/creator
requires work from Content Creator role

  
role/design
requires work from the design role

  
role/director
requires work from the director role

  
role/engineer
requires work from the engineer role

  
role/exec
requires work from the exec role

  
role/human
requires a person, and specifically not an agent seat

  
role/ops
requires work from the ops role

  
role/qa
requires work from the QA role

No labels
move-to-repo
coilyco-bridge-deploy
move-to-repo
coilyco-flight-deck-agent-compose
move-to-repo
coilyco-gaming-eco-app
move-to-repo
coilysiren-inbox
move-to-repo
unknown
🔒⚠️📦⚠️🔒 SANDBOXED 🔒⚠️📦⚠️🔒
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
c#
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo#161
No description provided.