NLWeb, WebMCP, MCP: A Technical Guide to Making Your Site Actionable by AI Agents

> In brief: this guide covers the technical implementation of the Agent-Ready level — NLWeb endpoint architecture, vector indexing, Schema.org structuring, and how to combine NLWeb with WebMCP and MCP on the same stack. It complements our guide to the 4 levels of agentic optimization, which remains the conceptual and strategic reference.

Knowing you need to "become agent-ready" says nothing about how to actually do it. Between the theory (SEO → GEO → AEO → Agent-Ready) and production, there's a concrete technical pipeline: structuring data, indexing a catalog, exposing an endpoint, securing actions. This guide details that pipeline, with the real-world experience of busony.com's NLWeb deployment.

Where NLWeb, WebMCP and MCP Fit in Your Stack

The three protocols aren't interchangeable — they address different needs and combine with each other:

In practice: NLWeb answers "what do you offer?", WebMCP answers "do it for me on this page", MCP answers "do it for me from my assistant, without me opening your site." A mature agent-ready site can deploy all three, but NLWeb is generally the fastest entry point to put into production — it's the one we detail here.

Common Prerequisite: Structure Your Data in Schema.org JSON-LD

Before exposing anything to an agent, your data must exist in a usable structured form — not just HTML dressed up with CSS. Schema.org in JSON-LD is the pivot format that NLWeb, GEO engines and most agents can read natively.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "SEO & GEO 360 Audit",
  "description": "Complete audit of your position across the 4 levels of agentic optimization: SEO, GEO, AEO, Agent-Ready.",
  "provider": { "@type": "Organization", "name": "Busony", "url": "https://busony.com" },
  "areaServed": "France",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

This same structure — name, description, offer, availability — then feeds the NLWeb index, WebMCP tools and MCP tools. One structuring effort, three protocols inherit from it.

Deploying an NLWeb Endpoint: Architecture and Implementation

The Principle: Vector Indexing of Your Catalog

NLWeb doesn't return HTML: it returns structured results ranked by relevance, from a free-text question. To do that, every service, product or piece of content on your site must be turned into a vector (embedding) and stored in a vector database queryable in milliseconds.

The typical pipeline:

1. Extraction: each service/product/page becomes a structured document (title, description, category, metadata). 2. Embedding: this document is turned into a numeric vector via an embedding model. 3. Indexing: the vector is stored in a vector engine — busony.com uses Qdrant — along with its metadata. 4. Query: the agent's question is itself turned into a vector, compared against the index, and the closest matches are returned with a relevance score.

The Query Endpoint

A minimal NLWeb endpoint exposes a single route, called via GET with the question as a parameter:

GET /ask?query=services+for+exporting+SME

Response (200 OK):
{
  "query": "services for exporting SME",
  "results": [
    { "name": "Exportik", "score": 94, "type": "Service", "url": "/en/exportik" },
    { "name": "SEO-GEO for exporting SMEs", "score": 91, "type": "Service", "url": "/en/secteurs/export" },
    { "name": "Agentic AI Optimization", "score": 87, "type": "Service", "url": "/en/ai-agents/agentic-optimization" }
  ]
}

On a Next.js stack, implementing this comes down to an API route that receives the query, embeds it, queries the vector engine and formats the response:

// app/api/ask/route.js — simplified example
export async function GET(request) {
  const query = new URL(request.url).searchParams.get('query');
  const queryVector = await embed(query);              // same embedding model as indexing
  const matches = await vectorDB.search(queryVector, {  // Qdrant, Pinecone, pgvector...
    limit: 10,
    scoreThreshold: 0.5,
  });
  return Response.json({
    query,
    results: matches.map(m => ({
      name: m.payload.name,
      score: Math.round(m.score * 100),
      type: m.payload.type,
      url: m.payload.url,
    })),
  });
}

Relevance Scoring: Where to Set the Threshold

A relevance score filters out noise — no point returning a result at 20% similarity, the agent won't use it. On busony.com, displayed results sit between 85 and 95: a realistic threshold for a medium-sized catalog (15 services) where each entry is well differentiated. On an e-commerce catalog with thousands of SKUs, the threshold often needs to be more permissive (60-70%) to avoid over-filtering close product variants.

Case Study: busony.com's NLWeb Deployment

busony.com has been running NLWeb in production since June 2026: 15 services indexed in Qdrant, relevance scores 85–95, responses under 200ms. The initial deployment — indexing the service catalog, setting up the endpoint, testing queries — took one day of work for a functional first POC. Ongoing maintenance consists of re-indexing whenever a service is added or changed, so the index never drifts from the content actually published on the site.

Maintenance Best Practices

• Automatic re-indexing: triggered on every content publish or edit, not just a nightly batch — an agent that receives an expired offer or an outdated price damages trust.
• Fine granularity: index at the service or product level, not the whole page — an agent is looking for a precise answer, not a 2,000-word document to summarize itself.
• Filtering metadata: category, geographic area, availability as metadata lets the agent filter without an extra query.
• Monitoring incoming queries: logging the questions agents ask reveals search intents your content doesn't yet cover.

Exposing Actions with WebMCP

NLWeb covers reading — WebMCP covers actions triggered from the browser, within the user's session (add to cart, booking, form submission), via the navigator.modelContext.registerTool() API. It's a protocol still in DevTrial (Chrome 146), with a specific security model — same-origin, CSP, mandatory user confirmation for sensitive actions. We've documented its implementation in detail, with code examples, in our dedicated WebMCP guide.

Connecting Agents via an MCP Server

For a Claude or compatible agent to interact with your systems without ever opening your site — checking availability, preparing a quote, querying your knowledge base — you need a dedicated backend MCP server, with its own authentication (OAuth 2.1 or API keys). MCP addresses a different need from WebMCP: it doesn't depend on a page being open in a browser. MCP's positioning relative to other agentic protocols is detailed in our MCP vs UDP article.

Securing the Agent Layer: Technical Checklist

Exposing data and actions to autonomous agents changes the threat model. A few principles to apply before any production deployment:

• Separate reading, recommending and executing: an endpoint that returns information should never share its permission level with an endpoint that triggers a real action.
• Authentication and scopes per action: each exposed tool (NLWeb, WebMCP, MCP) should have its own permissions, not global access to the whole API.
• Human validation on sensitive actions: payment, cancellation, personal data changes — explicit confirmation remains necessary even if the agent is authorized to initiate the action.
• Agent-specific rate limiting: agentic traffic has a different profile from human traffic (more frequent, more regular requests) — poorly calibrated rate limiting either breaks the agent experience or leaves the door open to abuse.
• Audit logs per agent and per action: in case of an anomaly, being able to trace which agent made which request, at what time, with what result.
• Real-time sync of sensitive data: pricing, stock, availability — an agent that passes outdated information to its user damages your brand as much as its own trust in the agent.

Technical Deployment Checklist

• Structured data in Schema.org JSON-LD for every service or product
• Indexing pipeline (extraction → embedding → vector database) documented and automated
• NLWeb endpoint tested with a representative set of queries, relevance scores validated
• Automatic re-indexing triggered on every content publish
• Sensitive actions exposed via WebMCP or MCP protected by human confirmation
• Authentication and scopes defined per tool, not global access
• Rate limiting and audit logs specific to agentic traffic
• Monitoring of incoming queries to identify uncovered search intents

Conclusion

The Agent-Ready level isn't a feature you check off once — it's infrastructure that needs ongoing maintenance, re-indexing and security, just like a regular website. The good news: the most cost-effective building block to deploy first, an NLWeb endpoint, requires neither a site redesign nor a deep architecture change — just a clean indexing pipeline and a well-designed endpoint.

Busony deploys NLWeb, prepares WebMCP and connects MCP for its clients — based on what we built and measured for busony.com itself.

Request a technical Agent-Ready audit →