Hold a tool listing for an hour, and give the roster a refresh that ends the wait early #363

New issue

Closed

opened 2026-08-13 11:05:26 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 11:05:26 +00:00

Member

Slice of #163, filed under the partial-delivery rule in AGENTS.md.

Kai's answer on 163 was a 1 hour TTL plus giving the agent the ability to refresh the MCP registry. That answer supersedes the decision recorded above it, which was boot-only resolution with cache-with-TTL explicitly rejected. Anyone reading 163 top to bottom will hit the older one first, so it is worth saying here too.

This issue is the TTL and the seam. The model-callable half stays on 163.

Scope

defaultRosterRefresh moves from 5 minutes to an hour.
MCPProvider.Refresh marks every rostered server stale so the next turn re-lists.

Why an hour is safe, which is the part I had wrong

I argued on 163 that lengthening the cache risked a server being unreachable for the life of the pod. That is true of removing the TTL and not of lengthening it, and the difference is a second trigger I had not accounted for.

dropSession sets tools to nil, and needsTools returns true whenever tools is nil. So a server that failed to list is retried on every turn its backoff allows, at any interval. The interval only governs servers that already answered successfully. The self-heal Kai's answer relies on is therefore already there and is not weakened by this change.

Why the refresh needs no rate limit

I said when I claimed 163 that I would bound this, because a model-triggered refresh looked like an outbound-connection surface. It is not. Refresh sets a flag and dials nothing. The listing happens on the next turn's Open, which happens once per turn regardless, so repeated calls collapse into one listing. Withdrawing that concern rather than shipping a bound for a risk that is not there.

Acceptance

An unlisted server ignores the interval.
A refresh causes a re-list inside the interval.
Repeated refreshes cost one listing, not one each.

Not in scope

The refresh the agent can invoke. Every tool Echo offers today comes from an MCP server, so a model-callable refresh means the first harness-native tool: a synthetic definition in Tools() and an intercept in Call before server dispatch, plus a rule for what happens when a rostered server publishes a tool of the same name. That is a new seam rather than a wiring change, and it stays on 163.

CLAIM - Angie (ENG, claude seat) 2026-08-13T11:06Z, 20 min. Carrying over from 163.

Slice of https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/163, filed under the partial-delivery rule in `AGENTS.md`. Kai's answer on 163 was a 1 hour TTL plus giving the agent the ability to refresh the MCP registry. **That answer supersedes the decision recorded above it**, which was boot-only resolution with cache-with-TTL explicitly rejected. Anyone reading 163 top to bottom will hit the older one first, so it is worth saying here too. This issue is the TTL and the seam. The model-callable half stays on 163. ## Scope - `defaultRosterRefresh` moves from 5 minutes to an hour. - `MCPProvider.Refresh` marks every rostered server stale so the next turn re-lists. ## Why an hour is safe, which is the part I had wrong I argued on 163 that lengthening the cache risked a server being unreachable for the life of the pod. That is true of **removing** the TTL and not of lengthening it, and the difference is a second trigger I had not accounted for. `dropSession` sets `tools` to nil, and `needsTools` returns true whenever `tools` is nil. So a server that failed to list is retried on every turn its backoff allows, at any interval. The interval only governs servers that already answered successfully. The self-heal Kai's answer relies on is therefore already there and is not weakened by this change. ## Why the refresh needs no rate limit I said when I claimed 163 that I would bound this, because a model-triggered refresh looked like an outbound-connection surface. It is not. `Refresh` sets a flag and dials nothing. The listing happens on the next turn's `Open`, which happens once per turn regardless, so repeated calls collapse into one listing. Withdrawing that concern rather than shipping a bound for a risk that is not there. ## Acceptance - An unlisted server ignores the interval. - A refresh causes a re-list inside the interval. - Repeated refreshes cost one listing, not one each. ## Not in scope The refresh the **agent** can invoke. Every tool Echo offers today comes from an MCP server, so a model-callable refresh means the first harness-native tool: a synthetic definition in `Tools()` and an intercept in `Call` before server dispatch, plus a rule for what happens when a rostered server publishes a tool of the same name. That is a new seam rather than a wiring change, and it stays on 163. **CLAIM - Angie (ENG, claude seat)** 2026-08-13T11:06Z, 20 min. Carrying over from 163.

coilyco-ops referenced this issue from a commit

2026-08-13 11:05:39 +00:00

feat(mcp): hold a tool listing for an hour, and let something end that early

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 11:05:53 +00:00

feat(mcp): hold a tool listing for an hour, and let something end that early #365

coilyco-ops referenced this issue

2026-08-13 11:06:23 +00:00

Tool discovery runs on every turn, for a surface that almost never changes #163

coilyco-ops closed this issue

2026-08-13 11:09:00 +00:00

coilyco-ops referenced this issue