Weekly Product Notes: Homepage, MCP Registry, and Discoverability

This note covers May 5 through May 11, 2026.

This week resolved a question that has been implicit in Bridge Town since early design: which surface is the primary interface? The answer is now structural. The homepage leads with an MCP install card. The MCP server passed a P0 security and spec-conformance audit. The discoverability layer was rebuilt from robots.txt up. Bridge Town is committing to agent-first as infrastructure, not as a tagline.

The homepage is now MCP-first

The biggest user-facing event this week was the homepage redesign.

The new homepage leads with an MCP install card as the dominant hero call to action. The message has shifted from “sign up for a planning tool” to “install the connector to your agent.” That is not a copy tweak — it reflects a product architecture decision that has been consistent for months but was not previously legible at the entry point.

The redesign was built on the Sand design-system token layer: the marketing surface now shares the same spacing, typography, and color contracts as the app. Core workflow product pages landed alongside it, giving the homepage links to real destinations for the first time. P0 navigation targets — previously linked but unresolved — now reach live pages or are hidden until they do.

What did not change: Bridge Town remains bring-your-own-agent. The install card connects your agent to Bridge Town’s MCP server. Bridge Town does not invoke server-side LLMs on your behalf, and the homepage does not imply otherwise.

The MCP server passed a registry-ready audit

While the homepage redesign was the visible work, the week’s heaviest technical lift was a P0 MCP audit and remediation sprint.

A comprehensive audit of the MCP surface — conducted against the 2025-11-25 spec and Anthropic’s remote connector guidance — produced a prioritized remediation backlog. By end of week, the sprint was closed: 90 tools documented with regenerated schemas and agent-usable examples, spec conformance on defer loading, progress reporting, and cancellation, and a registry submission package prepared.

Several security and RBAC changes were part of this sprint and are worth naming directly.

Cross-tenant model sharing is now request/accept. A tool call cannot write executable model code into another tenant’s Gitea repository without an explicit out-of-band acceptance step. The previous design had ambiguity in how sender-initiated sharing composed with write grants; that ambiguity is resolved.

Dashboard sharing now uses authenticated team links rather than anonymous public URLs. A previous design relied on presigned URL patterns that granted access without identity checks; the replacement design scopes access through normal auth. Additionally, dashboard share links now carry a real database-backed expiry — the expires_hours parameter is enforced at the server boundary, not just as a hint.

The CI conformance gate was added to catch regressions: the registry-wide test harness runs on main pushes and catches tool-count drift, truncated documentation, and schema inconsistencies before they reach the submission surface.

BYOK reached production grade

Bring-your-own-key encryption moved from enrollment infrastructure to full data-path coverage.

Two concrete changes landed. First, S3 uploads from the data service are now encrypted with tenant-specific CMK keys rather than the default AWS SSE. This closes the gap between enrollment (which was already CMK-scoped) and actual data writes. Second, the provisioning path now includes Gitea model-source configuration: tenants can specify their own Gitea endpoint for model-source operations, which is the foundation for self-hosted model storage.

The operational layer got more robust as well. A daily CMK health check now runs per enrolled tenant and triggers an alert when a key becomes inaccessible — which can happen through key rotation, policy changes, or accidental deletion. Without active monitoring, a CMK failure is silent until a model run attempts to decrypt data and fails. The health check makes CMK availability a proactive signal rather than a reactive incident.

The AI and SEO discovery surface was rebuilt

A focused sprint addressed how Bridge Town presents itself to crawlers, agents, and discovery systems.

The AI discovery files (llms.txt, llms-full.txt) were made spec-complete. The previous version had stale wording around MCP transports and omitted capabilities; the new version reflects the 1.0 tool surface and connector contract accurately. JSON-LD structured data was added to commercial pages, making pricing, use-case, and comparison pages parseable by structured crawlers and LLM retrieval pipelines.

On the search side, robots.txt was updated to make crawler policy explicit — GPTBot now has a clear directive — and the marketing sitemap was extended to cover /resources and /compare with accurate lastmod timestamps. Markdown shadow routes and alternate links were added so AI agents that prefer flat content retrieval have a parallel surface to the rendered HTML.

New content pages landed under the audience and compare paths, giving the homepage external link targets and providing the SEO surface with indexable pages for core use cases.

Dark mode shipped end to end

Dark mode rolled out across the full app surface. The implementation covers the app chrome, component layer, and the landing site, with theme persistence across Bridge Town subdomains — the setting you choose on www.bridgetown.builders carries into app.bridgetown.builders.

A subtle but important fix landed alongside it: theme toggling now sets data-theme atomically with the .dark class, eliminating a flash-of-wrong-theme on initial load that could occur when the class transition and attribute update were not synchronous.

The design system also added a model diff view component, an MCP tool result card pattern, and mock primitives for agent thread rendering — foundational elements for agent-observable workflows in the app.

Compliance pages for enterprise buyers

A batch of compliance content landed for enterprise and procurement audiences: subprocessors listing, DPA/security pages, and a conformance test suite covering the new routes. These are not product features in the user-facing sense, but they matter at the stage of the sale where a buyer’s security team is reviewing. The public claim language was also swept to remove unsubstantiated assertions about certifications and compliance posture.

Deploy and test infrastructure tightened up

Two defensive measures landed on the deployment path.

A conflict-marker guard now runs on main pushes and deploy builds. Merge artifacts (<<<<<<<, =======, >>>>>>>) in committed files have caused silent build failures in the past; the guard catches them before they compound into harder-to-diagnose issues later.

The EC2 deploy rollback path was hardened: the deploy runner now handles smoke failures and drift checks more robustly, with explicit rollback behavior rather than silent failure on problematic states.

What this means

By May 11, Bridge Town is no longer explaining itself from the inside out.

The homepage, the MCP surface, and the discoverability layer now tell the same story: a version-controlled FP&A substrate that agents connect to through a well-specified, registry-ready interface, with per-tenant encryption and authenticated sharing as the security defaults.

What comes next is product depth on top of these foundations. The MCP connector surface is now ready for external scrutiny; the next move is making the agent workflows it enables richer and more auditable. The BYOK layer covers data at rest; the next move is making key lifecycle and rotation visible in the product. The homepage leads with the install card; the next move is making the first-run experience after install as clear as the homepage copy.

The structural work this week creates room for that.