NLWeb: Tapping MCP for natural language web search

Technologies like Model Context Protocol (MCP) are reshaping both how we build AI-powered applications and what we can do with them. By providing a standard way of describing and accessing information stored in our applications, MCP makes it easier to add AI features to existing code and services. MCP also unlocks the ability to access that information with new user interfaces and support for software agents.

It’s still early days for what Microsoft CTO Kevin Scott calls “the agentic web,” but he suggests that MCP may be the equivalent of HTTP for interconnected AI applications. Certainly, Microsoft has made a big bet on the evolving protocol to provide real-world uses for AI and as a tool to reduce the risks associated with ungrounded chatbots.

MCP and the natural language web

That bet has resulted in many different experiments and projects, across the company and its various divisions. One of the more interesting approaches is intended to standardize building natural language interfaces for websites and web applications. This builds on one of the strengths of modern generative AI models, their ability to transcribe speech and assign intent to the results, providing a new level of accessibility as well as supporting machine-to-machine interactions.

Announced at Build 2025, NLWeb is an open project that’s intended to run alongside existing web properties, allowing the use of any model to add voice and text inputs that go beyond basic click-based navigation. NLWeb is designed to be platform-agnostic. It will work in most OSes and with common models and data tools.

This can be done relatively easily as the web is built on semi-structured semantic descriptions of content, from the basic document structure embodied in HTML to higher-level tools like RSS and micro-formats, as well as newer technologies like web components. You can also take advantage of technologies like the common entity descriptions offered by Schema.org.

Using the semantic web for AI-powered search

The intent with NLWeb is to build a contextual semantic search layer for any website. As well as using web content, it should be able to bring in information from other sources, including the training data encoded in the large language model (LLM) used as part of the application. At the same time, each NLWeb implementation is a MCP server, allowing it to be used in larger-scale agent orchestrations, as part of a dynamically composed application.

Microsoft and its partners are developing NLWeb in the open on GitHub, providing the code necessary to build your first implementation and connect it to a web application, as well as a protocol that uses JSON over REST to use natural language to send queries to a server. The NLWeb service sits on top of a MCP server, with one standard method, called ask, to handle delivering natural language queries.

The best results for NLWeb come with websites that are already structured as what it describes as “lists of items.” That includes recipes, events, places, and more, as many of these use Schema.org to embed microdata in HTML content.

This preparation can be as simple as wrapping content in Schema.org-defined attributes, using itemscope and itemprop to add definitions and tie them to defined hierarchies, or using item types like Think and Place. Because many sites use Schema.org microdata to provide machine-readable structures to page content for search engine indexing, it’s not surprising that most LLMs trained on web content are able to recognize and parse it, in much the same way as they support OpenAPI definitions.

Using NLWeb with Schema.org content descriptions

NLWeb works much the same way as a traditional website search, without requiring a specialized set of algorithms for each site. Instead, it takes advantage of the capabilities of an AI-powered approach to adapt to your site’s content. That makes it both cheaper to implement and easier to deploy. At the same time, unlike chatbots, responses are returned as JSON objects, giving you control over what is displayed and how it’s formatted.

At the same time, as queries are grounded in your website data, and results returned as lists, you’re able to first check for relevance and errors and reject incorrect responses.

One key component of NLWeb is its tool support, the ability to load additional processing features based on the current user query. Tools are defined in an XML configuration file and associated with a Schema.org type. So, for example, if we’re searching a list of content, we can pull up the tools that work with the type. Each tool has a prompt that helps you choose which type to be used with the current query.

The currently available tools include the default search tool, an item details tool that gets information about a specific item, a comparison tool that helps evaluate two different items, and an ensemble queries tool that brings different queries together, for example to help plan a tour or put together a reading list of articles on a set of topics.

More specialized tools can be added, with a set of tools for working with recipes part of the first release. These can help substitute ingredients or find the right accompaniments. For your own use cases and content, you can define and add your own tools for your own specific use case, working with the project code and extending and changing as necessary. Future developments may allow MCP servers to be used as tools.

Getting started with NLWeb

The NLWeb development team offers a handful of quick starts to help you deploy your first NLWeb instances. These start with a basic local instance, running in a Python virtual environment with a vector database. You will need access to a LLM endpoint, with the default being Azure OpenAI, for inferencing and for generating the embeddings that are stored in your vector database. The demonstration search works against a set of RSS feeds, and you can quickly add your own choices. RSS feeds are a good first choice for a structured source of web content, as the RDF format offers many of the features NLWeb requires to generate answers.

The first thing to do is to load the feeds into the vector database, using a load script that manages embeddings and creates a vector index for your search. You can have multiple RSS feeds at the same time, to increase the complexity of the available search. Once the database is loaded, you are ready to use the NLWeb server’s web UI to run your first searches. Other options for your first server include running it on Azure and running it in Docker. Google Cloud Platform and AWS examples are on the way.

If you want to explore the service in more detail, NLWeb offers a REST API that can be used for queries (/ask endpoint) or as an MCP server (/mcp endpoint) for use in agent-to-agent applications. The API arguments are the same for both endpoints; the only difference is the format of the returned object, which for MCP calls is a JSON object in MCP format. It’s important to note that the current NLWeb implementation is stateless, so if you want to keep context between calls you will need to manage earlier prompts and responses and use them to build new queries.

The GitHub repository for NLWeb has a set of JavaScript UI components that can be used build a basic interface for the service. You can use these to quickly put together a prototype, or build on them to deliver something more like your existing site design. Hopefully, future releases will move to using technologies like web components, so that setting up the UI side of NLWeb becomes a simple operation — either cut and paste or drag and drop, depending on the web development tools you’re using.

Results are displayed in either a drop-down menu or in a classic search engine UI. Both options allow you to refine results by giving more context through a chat. NLWeb can be used to render results based on their Schema.org item type. A sample recipe display script is included as part of the NLWeb repository.

A partner-driven project

The initial list of publishers and platforms working on NLWeb includes publishers like O’Reilly, content-driven services like Tripadvisor, and data platforms like Snowflake. The partners comprise an interesting cross-section of the modern web, and it will be interesting to see how uptake develops.

The cross-industry set of partners underscore the ambition behind NLWeb, building a tool that quickly extends any web application with natural language interactions. A tool like this needs to be as open as possible, both to be part of the web and to build on the web’s openness. Hopefully, as NLWeb evolves, Microsoft and its partners will standardize the APIs, passing them on to a body like the W3C to ensure widespread adoption.