Delivering Gantry's Tools to Any Harness's Assistant
The conversational assistant reached its run tools only under Claude; this job taught every harness to register them natively.
0 milestones 5 sprints
1h 6m total 7m 40s per sprint
26.2M tokens in 144.1k tokens out
$26.74 nominal cost
Gantry can run a conversational assistant beside a build, with its commands and file reads routed through gantry's own MCP bridge. That bridge already existed, but the registration path was Claude-shaped: the shared driver wrote a project config file that other harnesses did not read.
This job moved the assistant's MCP registration into the harness layer. The run-scoped server is described once as neutral data, then each supported harness renders that description in the form its own CLI accepts.
How this walkthrough is structured
Feature
What did the run build and ship?
The assistant now receives gantry's run tools through the selected harness's native MCP mechanism, with the neutral server description still present in the harness module and the host.
Build
How did Gantry structure the work?
The run separated neutral registration, generic delivery, per-harness renderers, and the final driver switch so each fresh agent could prove one boundary before the assistant wiring depended on it.
Neutral MCP Registration
0 agents 7m 40s wall time 19.8k tokens out $3.34 nominal cost
The neutral server spec is still in the harness module, with name, command, and args fields. The assistant MCP host still exposes a `gantry-run` registration for `gantry mcp-bridge` and renders Claude's config from that same data rather than building a separate JSON value. The separate brain source touched by the sprint has since been folded away, but the shared type and host behavior remain visible in the live tree.
This first cut carried only the shared data model. The brief asked for a neutral stdio server description, an optional field on the agent spec, and a host refactor that made that description the source of truth while leaving the old file write in place. That was small enough for a fresh agent because no harness had to consume the field yet. Its gate stayed green, which fits the boundary: this sprint changed the representation and tests, not the live assistant path.
Delivery Seam Architecture
0 agents 9m 26s wall time 27.3k tokens out $5.88 nominal cost
`McpDelivery` still has the file and no-file variants, and the runner still writes declared MCP files into the worktree while excluding them from git. Claude still turns a nonempty registration into `.mcp.json`, and an empty registration leaves one-shot invocations without an MCP file. The runner also now creates parent directories for file delivery paths, a later need that lives in the same realization code.
This sprint made delivery a harness decision instead of driver code. Its brief was to add an invocation-level MCP delivery shape, teach the runner to realize file deliveries, and prove the path with Claude's project config renderer. The cut was narrow because it did not need Codex, Gemini, OpenCode, or the brain switch to be live yet. It completed without a recorded repair or re-plan, leaving the interface ready for the other harnesses.
Codex MCP Delivery
0 agents 4m 12s wall time 10.2k tokens out $1.99 nominal cost
The Codex invocation still renders run-scoped MCP servers as `mcp_servers` config overrides on the command line. It keeps the prompt as the final argv element, declares no MCP file, and appends nothing when the spec carries no registration. The tests in the live plugin still pin quoted command values and string-array args, which is the part that prevents the assistant from silently losing its Gantry tools.
Codex was the harness that made the bug user-visible, so this sprint carried the highest semantic risk while staying confined to one plugin. The brief centered on command-line config overrides and on TOML encoding, because a bad value would be ignored by Codex rather than caught by a file writer. The run facts record a green boundary with no recovery. That says the planner had isolated the fragile format work behind unit tests rather than making it part of the final driver flip.
Gemini and OpenCode Delivery
0 agents 5m 55s wall time 16.5k tokens out $4.03 nominal cost
Gemini still declares `.gemini/settings.json` with an `mcpServers` block when a registration is present. OpenCode still declares `opencode.json` with its own local server shape, including a fused command array and enabled flag. Both plugins leave argv behavior alone when there is no registration, and the shared runner support for nested delivery paths remains in place for Gemini's config directory.
This sprint grouped the remaining harnesses because both used file delivery and differed mainly in their native schema. The brief asked the agent to verify each config shape, render the neutral registration into that shape, and extend the runner if nested paths were required. That is a mechanical propagation sprint with one small shared-runner consequence. It also stayed green, so the file-delivery abstraction held across more than Claude.
Brain Driver Migration
0 agents 19m 28s wall time 36.9k tokens out $6.05 nominal cost
The driver path now carries the host's neutral registration into the assistant spec, and the resolved harness decides how to deliver it. `gantry agent` and the chat-side console wiring both obtain MCP servers from the host and pass them into the assistant driver. The old direct `.mcp.json` write is no longer the live mechanism; the standalone brain module that once held part of this work has since been consolidated into chat and command wiring.
The final sprint was the integration point: it stopped the assistant driver from writing a Claude config directly and made it populate the neutral spec field instead. This piece depended on every earlier renderer, so it was intentionally sequenced after all native delivery paths were testable. The record shows an extra successful gate at this boundary, but no failed gate, recovery, or re-plan. That extra proof belonged where the whole integrated tree first exercised the new route.