NLWeb

What it is

NLWeb is a collection of open protocols and open-source tools for building conversational interfaces for websites^[1]. The goal is a site that can be asked a question in ordinary language and answer it, instead of only offering menus, search boxes and lists of links. The project is framed as a small shared layer rather than a single product: a common way for many sites to expose the same kind of question-and-answer surface.

How it works

The design has two parts. The first is a simple protocol that interacts with a site in natural language and returns JSON using Schema.org^[1]. The second is an implementation that uses existing site markup^[1]. Because it builds on Schema.org and semi-structured formats such as RSS, it starts from formats the project says are used by more than 100 million websites^[1]. The practical point of leaning on markup that sites already publish is that a site can answer questions without first designing a new data model for its content.

On the serving side, every NLWeb instance also acts as an MCP server and supports a core method called `ask`^[1]. Support for the Model Context Protocol is native, so the same natural-language APIs serve both humans and AI agents^[1]. A person typing a question into a site's chat box and an agent calling the site on someone's behalf reach the same interface and get answers in the same shape.

The project describes NLWeb as being to MCP and A2A what HTML is to HTTP^[1]. The analogy is about layering. HTTP moves bytes between machines but says nothing about how a document is organised, so HTML supplied a shared format that any client could read. MCP and A2A are protocols through which AI systems call tools and other agents; NLWeb is meant to be the shared format for the conversation itself, so that a site's answers look the same whichever client is asking.

What it runs on

NLWeb is platform-agnostic and supports Windows, macOS and Linux^[1]. It is designed to run from data-centre clusters down to laptops and, before long, mobile devices^[1]. That range matters for a protocol meant to be adopted widely: a small site can try it on a single machine, while a large one can run it across a cluster.

Storage and models are pluggable. Supported vector stores include Qdrant, Snowflake, Milvus, Azure AI Search, Elasticsearch, Postgres and Cloudflare AutoRAG^[1]. A vector store is where the numerical representations of a site's content are kept so that the passages most relevant to a question can be retrieved and passed to a model. Supported model providers include OpenAI, DeepSeek, Gemini, Anthropic, Inception and Hugging Face^[1]. The list covers both large hosted services and open-weight models, which leaves the choice of model to whoever deploys the site.

Where it sits

When checked, the public repository carried an MIT licence and had 6.3k stars and 695 forks^[1]. The permissive licence and the spread of supported stores and model providers point at the same ambition as the protocol design: to be a thin, common layer that sites and agent builders can adopt without committing to one vendor's stack. Its position in the field follows from that — as more AI agents act as the client for web content, a standard way for a site to answer a natural-language question becomes as useful as a standard way to serve a page.

A conversational interface built this way is only as good as the markup and retrieval behind it, and the project's own description is about plumbing rather than results: it specifies how questions are asked and how answers come back, not what a given site should say.