· Bridge Town Editorial · Releases · 4 min read
Weekly Product Notes: MCP Foundations and Run Hardening
A retrospective on the first week of April, when Bridge Town moved the MCP surface, production path, sandbox runtime, and project language onto stronger foundations.
This retrospective covers April 1 through April 6, 2026.
The first week of April was a foundation week. Bridge Town moved more of the product from prototype-shaped surfaces toward production contracts: MCP transport changed, tool metadata became more explicit, model execution became easier to diagnose, and the deploy path picked up the checks needed for real users.
Most of the work is not a single feature screen. It is the substrate that makes the rest of the app feel predictable.
MCP moved to a cleaner contract
The biggest platform shift was the move from the older SSE model to Streamable HTTP for MCP.
That change was paired with Dynamic Client Registration, OAuth proxy compatibility for Claude.ai, PKCE enforcement for public clients, token revocation, and a set of fixes around reverse-proxy URLs. In practice, Bridge Town became easier to connect from external agents without asking users to reason through deployment topology.
The tool surface also became more machine-readable. MCP tools gained outputSchema, annotations, read-only hints, stronger structured error handling, and clearer naming conventions. health_check and scaffold discovery began moving into resource-style surfaces, while older aliases and duplicate paths were reduced.
This was the start of a sharper contract: agents should be able to discover what exists, understand the shape of outputs, and recover from errors without guessing.
Project language started replacing repo language
The product language continued moving from implementation terms toward user-facing terms.
The app and tool descriptions began standardizing on project_name, with repo-oriented aliases and route references removed or reduced. That change matters because finance teams are not coming to Bridge Town to manage repositories. They are managing planning projects, model files, data sources, runs, and decisions.
This week also changed visible navigation language such as “Browse models” toward “Browse files” and updated dashboard statistics to reflect projects rather than internal repo counts.
Model execution got easier to operate
Run execution picked up several reliability improvements.
The sandbox runner moved toward a run.py entrypoint, better output discovery, and clearer fallback behavior when a model produced stdout JSON or empty outputs. Run responses began including more useful diagnostics, stdout and stderr were capped to safer sizes, and timeouts were separated from other sandbox failure modes.
Branch-aware execution also started to take shape. Reads, writes, rollback, queueing, and run status flows gained more branch context, and list_files arrived as an MCP tool so agents could inspect project contents before making changes.
For users, this meant fewer “the run failed, but why?” moments. For agents, it meant less blind probing.
Production and sandbox security were tightened
The week included a large security pass across production, auth, and sandboxing.
Sandbox containers were hardened with non-root execution, dropped capabilities, import hook restoration, safer Docker SDK usage, stricter output handling, and better cancellation behavior. Production guardrails were added around BYPASS_AUTH, Redis auth, KMS encryption for CloudWatch logs, token handling, redirect URI validation, API token prefix collisions, CSP behavior, and Google Sheets encryption requirements.
There was also work on RLS policy coverage, cross-tenant access alarms, audit logging, and tenant provisioning races. Much of this is invisible when it works. That is the point.
Deployment became less fragile
Bridge Town’s production path received concentrated attention.
The app added EC2 auto-deploy workflow support, production Docker and Caddy fixes, environment-aware MCP URLs, proxy headers behind Caddy, deploy smoke checks, rollback tagging, and staging smoke automation. Vercel configuration for the web and landing surfaces was corrected so project boundaries were clearer.
The week also included CI cleanup, Semgrep and Trivy adjustments, dependency pinning, and broader test coverage across middleware, API contracts, auth, dashboards, Google OAuth, and web components.
The result was not just more tests. It was a deploy path that could explain more of its own failures.
Public surfaces began matching the product
The landing site, docs site, and legal pages were brought closer to the Bridge Town visual language. PostHog landed on both the Astro marketing site and the Next.js app, with consent and privacy updates, while docs pages were regenerated for the newer execution tools.
Bridge Town also prepared MCP registry submission materials, reviewer tenants, sample data, and extension screenshots. That work helped turn the MCP integration from “it works locally” into something ready to show and review externally.
What this means
By the end of the week, Bridge Town had a stronger operating base:
- MCP clients could connect through a more standard transport.
- Tools had clearer schemas, names, annotations, and errors.
- Project language was replacing implementation language.
- Runs were easier to execute, inspect, and recover.
- Production deployment and sandbox security were less brittle.
This was infrastructure work, but it was product work too. It made later collaboration, Google Sheets, scenario, and notes features possible without stacking them on uncertain contracts.
