feat(mcp): land the harness refresh tool on main

coilyco-ops commented

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

Member

The hour from 363 is only safe if something can end it early, and the thing
best placed to notice a missing tool is the model that just failed to find one.
This is the tool it uses to say so, and the first tool Echo offers that does
not belong to an MCP server.

The collision question I raised on 163 was already answered by the code. The
name is built by the same server__tool rule with harness as the server, so a
rostered server publishing it hits register's existing fatal collision, whose
comment says degrading past it would silently drop whichever tool lost.

Two of the five tests this broke were telling me something. An empty roster is
a documented no-tool capability boundary, so the refresh is offered only when
the roster is non-empty; a tool in the one configuration meant to have none is
a capability claim with nothing behind it. And the proxy test asserts what
reaches the model at the wire, where the count moving from 1 to 2 is the real
change here.

The other four assertions stay exact counts rather than becoming contains
checks. An exact count is what fails when a tool nobody intended appears.

The result text and the description both say the new list lands on the next
turn. A model reading otherwise would tell a member a tool is available before
it can see one, which is 211.

The doc split out rather than squeezing the roster doc past its cap. The first
harness-owned tool is its own concept and a later second one lands beside it.

closes #377

Co-authored-by: Kai Siren coilysiren@gmail.com
Co-authored-by: Claude noreply@anthropic.com

Re-applied onto main after the original merged into its own stale base branch
and never reached the product. Conflict resolved against 369, which moved the
MCP numbers into tuning.go; the tool names and the model-facing description are
not numbers and stay in mcp.go.

Co-authored-by: Kai Siren coilysiren@gmail.com
Co-authored-by: Claude noreply@anthropic.com

The hour from 363 is only safe if something can end it early, and the thing best placed to notice a missing tool is the model that just failed to find one. This is the tool it uses to say so, and the first tool Echo offers that does not belong to an MCP server. The collision question I raised on 163 was already answered by the code. The name is built by the same server__tool rule with harness as the server, so a rostered server publishing it hits register's existing fatal collision, whose comment says degrading past it would silently drop whichever tool lost. Two of the five tests this broke were telling me something. An empty roster is a documented no-tool capability boundary, so the refresh is offered only when the roster is non-empty; a tool in the one configuration meant to have none is a capability claim with nothing behind it. And the proxy test asserts what reaches the model at the wire, where the count moving from 1 to 2 is the real change here. The other four assertions stay exact counts rather than becoming contains checks. An exact count is what fails when a tool nobody intended appears. The result text and the description both say the new list lands on the next turn. A model reading otherwise would tell a member a tool is available before it can see one, which is 211. The doc split out rather than squeezing the roster doc past its cap. The first harness-owned tool is its own concept and a later second one lands beside it. closes #377 Co-authored-by: Kai Siren <coilysiren@gmail.com> Co-authored-by: Claude <noreply@anthropic.com> Re-applied onto main after the original merged into its own stale base branch and never reached the product. Conflict resolved against 369, which moved the MCP numbers into tuning.go; the tool names and the model-facing description are not numbers and stay in mcp.go. Co-authored-by: Kai Siren <coilysiren@gmail.com> Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops added 1 commit

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

feat(mcp): let the agent end the roster's hour when it notices a gap

ci / test (pull_request) Successful in 31s

Details

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

Details

ci / publish-observed (pull_request) Has been skipped

Details

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

Details

031ffa8ce2

The hour from 363 is only safe if something can end it early, and the thing
best placed to notice a missing tool is the model that just failed to find one.
This is the tool it uses to say so, and the first tool Echo offers that does
not belong to an MCP server.

The collision question I raised on 163 was already answered by the code. The
name is built by the same server__tool rule with harness as the server, so a
rostered server publishing it hits register's existing fatal collision, whose
comment says degrading past it would silently drop whichever tool lost.

Two of the five tests this broke were telling me something. An empty roster is
a documented no-tool capability boundary, so the refresh is offered only when
the roster is non-empty; a tool in the one configuration meant to have none is
a capability claim with nothing behind it. And the proxy test asserts what
reaches the model at the wire, where the count moving from 1 to 2 is the real
change here.

The other four assertions stay exact counts rather than becoming contains
checks. An exact count is what fails when a tool nobody intended appears.

The result text and the description both say the new list lands on the next
turn. A model reading otherwise would tell a member a tool is available before
it can see one, which is 211.

The doc split out rather than squeezing the roster doc past its cap. The first
harness-owned tool is its own concept and a later second one lands beside it.

closes #377

Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

Re-applied onto main after the original merged into its own stale base branch
and never reached the product. Conflict resolved against 369, which moved the
MCP numbers into tuning.go; the tool names and the model-facing description are
not numbers and stay in mcp.go.

Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

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

coilyco-ops referenced this pull request

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

A stacked pull request merged into its own base and reported success while the code never reached main #377

coilyco-ops added 1 commit

2026-08-13 11:27:59 +00:00

Merge branch 'main' into fix/land-the-harness-refresh-on-main

ci / test (pull_request) Successful in 30s

Details

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

Details