How I Built WebMCP on Human’s Website With Sanity

A marketing website should be able to answer a simple question: what can you help me do? For a person, that answer might come from reading a service page, browsing our team, or opening a contact form. For an AI assistant working on that person’s behalf, the same task can involve interpreting page layouts and piecing together information from different places.

I wanted to give that assistant a more direct way to work with our own website (the one you’re on right now). As Human’s Senior Developer, I implemented WebMCP alongside a remote MCP (Model Context Protocol) connection, using the structured content already in our Sanity Studio, the content management system (CMS) behind our website. The result is a set of eight tools that can return information about Human and, when a visitor requests it, pass their contact details to our team.

Building this on our own site gave me a practical way to explore how agents could use the content we already maintain. It also raised a few questions: which tasks should an assistant handle, how could Sanity support them, and how could we make those capabilities clear to visitors?

Main Points

• Human’s site now exposes eight defined tools, covering content discovery, guided journeys, fit assessment, and contact submission.
• Sanity supplies the published content behind the tools, while shared application code defines how each tool behaves.
• I used Claude Code, Cursor/Grok, and Sanity’s MCP to help build the implementation and assemble the dedicated WebMCP page.
• The floating Human / Machine / MCP widget makes the different ways of using the site visible to visitors.
• This is a working implementation we can learn from; it does not establish a lift in traffic, leads, or revenue.

Start with what a visitor needs to do¶

The useful starting point was the website itself. We already had service descriptions, articles, team profiles, and published case studies. A prospective customer might want to understand our capabilities, find useful reading, or decide whether to start a conversation. Those are concrete tasks that an assistant should be able to help with.

WebMCP is a proposed web standard that lets a website expose named tools, each with a description and defined inputs, to AI agents working in the browser. Instead of requiring an agent to infer every interaction from the page, the site can tell it which operations are available. In our implementation, those operations call application logic that we control.

I built two ways for compatible AI assistants to use our site: in the browser through document.modelContext, or through a direct connection from an AI app. Both use the same content and tools to help visitors explore our services, find relevant examples of our work, and decide whether to contact us.

Support for this technology is still developing, so I made sure visitors can always browse the site as usual. Those using a compatible assistant have another way to get answers without having to search through every page themselves.

Use the content we already maintain in Sanity¶

Our website runs on Next.js with Sanity as its content platform. Sanity stores content as structured documents and fields: a service has a title, description, and page address; an article has categories, an author, a publication date, and more. That structure gave me a useful foundation for the tools.

I added a shared query layer that reads published Sanity content and returns selected fields as structured data. The service tool, for example, can return a service’s title, summary, and link. It does not need to extract those details from the visual page.

The practical benefit is maintenance. Our team can update the source content in Sanity without maintaining a second set of service descriptions just for agents. The website and the tool responses draw from the same content platform. Normal caching still applies, so an edit can take a short time to appear everywhere.

I also kept the tool definitions in one registry. Each entry names the operation, explains its purpose, and describes the inputs it accepts. That registry supplies the browser registration, the remote tool listing, the discovery description, and the visible tool catalog. It reduces the number of places that need to change when a tool changes.

The eight tools I added¶

The current tool set covers a small, useful range of actions: seven retrieve information or calculate a response, and one submits information.

• get_guided_journey returns an ordered path through relevant parts of the site, using a visitor type or a short description. The configured journeys cover ecommerce visitors, local or franchise businesses, and job seekers.
• assess_fit returns an initial fit score, an explanation, recommended services, published case studies, and a suggested next step for a business prospect.
• get_services retrieves the services we offer, with summaries and links, or narrows the result to a particular service.
• get_case_studies retrieves published case-study pages so an assistant can point a visitor toward our work.
• get_team retrieves team profiles and supports filters such as name or role.
• lead_capture submits visitor-provided contact information to our HubSpot contact workflow.
• search_site searches pages and blog posts, returning matching titles, summaries, and links.
• get_blog_posts retrieves articles and can filter them by topic, audience, or a specific post.

A guided journey is a recommendation, not a command that takes over someone’s browser. It returns steps and links. I renamed the original navigate tool to get_guided_journey during development because the more specific name better describes what it returns.

The fit assessment also has a defined limit. Its score comes from rules in our code, including recognized business types, service needs, and whether goals and a budget were provided. It is an opening assessment, not a prediction of business results or a substitute for a strategist’s discovery conversation. The score notes whether a budget was provided, not whether the amount is enough.

Lead capture has a different consequence: it sends information to our team. Its description tells an agent to use it only after the visitor provides their own details and agrees to be contacted. The implementation validates required fields and includes a basic rate limit. The consent instruction still needs to be honored by the calling assistant; a tool description alone is not an enforcement mechanism.

Make the machine-facing side visible¶

The floating widget at the bottom of the site gives visitors three options: Human, Machine, and MCP. Human is the familiar website you’re reading now. Machine displays a plain-text (Markdown) version of the current page. MCP opens the list of available tools.

Figure 1. Human-readable text, agent-friendly Markdown, and all eight MCP tools. Descriptions shortened for clarity.

These serve different purposes. Machine mode makes page content easier to inspect in a text format. The MCP panel explains the operations an assistant can call. Opening that panel does not itself run a tool or enable browser support; it is a visible guide to what the site exposes.

The panel uses the shared registry, so its tool descriptions come from the same definitions used by the integration. I also added discovery information at /.well-known/mcp.json and a dynamically generated /llms.txt. Those give compatible tools and curious developers more ways to understand what is available.

Build the WebMCP page with Sanity and its MCP¶

A tool endpoint is useful to software, but people need context. The dedicated WebMCP page explains the purpose of the integration, how a call reaches the site, what each tool accepts, and where to go next.

I used Claude Code and Cursor/Grok models in the development work, and Sanity’s MCP to help generate appropriate content and assemble it within our content model. In this context, Sanity’s MCP was part of the authoring workflow. Our public WebMCP tools are the separate interface visitors’ assistants can use.

Our Sanity page builder is organized around modules: reusable sections with defined fields and corresponding frontend components. That gave the AI-assisted work an existing structure to follow. Content could be created for the modules we already supported, and new behavior could be added where the page required it.

The published page combines seven sections. Six reuse existing modules: a hero, a flow chart, a description list for use cases, an accordion for FAQs, a comparison of human and agent browsing, and a closing callout. The new section is the MCP tool catalog. It all runs on our proprietary version of the Next.js + Sanity starter template I built.

That catalog is a useful example of where I drew the boundary between editorial content and application behavior. Sanity stores the section’s introduction and display options. The actual tool names, descriptions, parameters, and example requests come from the code registry. An editor can change the surrounding explanation without separately maintaining a technical inventory.

Adding that module required both a Sanity schema and a frontend component, then registering them with the page builder. Sanity’s MCP helped with the content side; the coding tools helped with the implementation. Creating a new section type still meant making sure the website knew how to render it.

For a marketing team, the value is flexibility within a consistent system. We could build a page for a new capability using familiar sections, extend the system where needed, and leave the explanatory copy editable in Sanity.

What changed between the first version and production¶

The first version, built in June, included the tool registry, browser registration, remote connection, and widget. Over the next two months, I added lead capture, the llms.txt file, and the tool catalog module. I also renamed navigate to get_guided_journey, updated the browser integration to prefer document.modelContext as the WebMCP proposal evolved, and fixed a rendering issue. The result is the version you see today: eight tools, a floating widget, and a dedicated WebMCP page.

We’ve also added PostHog tracking to see which tools are being used, how often they’re used, and where they run into problems. We can track when visitors open the widget or switch between views, too. That gives us a way to learn from actual usage and decide what to improve next.

Frequently asked questions¶

Is this a chatbot on Human’s website?¶

No. The implementation exposes defined operations that a compatible assistant can call. The floating panel lists those operations; it is not a chat interface.

Do visitors need a special browser?¶

People can browse the site normally. Calling tools through the browser’s WebMCP API requires a supporting environment. A compatible remote MCP client can use our separate /api/mcp connection. Showing the MCP widget does not mean every browser can execute its tools.

Can an agent edit the website through these public tools?¶

The published tool set does not provide Sanity editing or publishing access. Seven tools read information or return a calculated response. Lead capture submits contact details to HubSpot. Sanity’s authoring MCP serves a separate purpose and uses its own authenticated access.

Does adding WebMCP guarantee better AI visibility?¶

No. It gives compatible agents a defined way to request information and take supported actions. It does not guarantee discovery, citations, rankings, or recommendations. Accurate source content and a useful website still matter.

Build something useful, then learn from it¶

The most valuable part of this project was connecting a new interface to content and business logic we already maintain. Sanity supplied the structure. The shared tool registry kept the integration consistent. The widget and dedicated page made the work understandable to people.

Our broader post, “How Human Uses AI Agents (and Where Humans Still Make the Call),” explains how this fits into the way we are experimenting with AI across the agency. You can also explore the live WebMCP page to see this implementation for yourself.

If you are considering a similar capability for your brand, talk with our team about what your customers need an assistant to do. Human helps ecommerce and B2B brands connect marketing strategy, content, and development. This project is one example of putting those disciplines together on our own site.