The MCP Endpoint as a Product Surface

Your agent works in the demo. Then a customer asks it which warranty applies to a product that shipped last quarter, and it confidently cites a policy that was retired in March. The retrieval layer returned a stale chunk, the model wrapped it in fluent prose, and nobody in the editorial chain ever saw the answer before it reached production. The endpoint your agent talks to was treated as plumbing, so it got none of the review, versioning, or governance you apply to everything else you ship.

That gap is the subject of this article. The connection point between an agent and your content, the MCP endpoint, is not infrastructure to be hidden behind a glue layer. It is a product surface, with the same demands for freshness, observability, staging, and access control as any customer-facing API. Sanity Context (the Sanity product for grounding AI agents in structured content) treats it exactly that way. Sanity is the Content Operating System for the AI era, an intelligent backend designed to keep agent retrieval governed, reviewable, and safe inside the editorial loop rather than bolted on beside it.

This guide reframes the endpoint as something you design, test, and release, and shows what changes when the retrieval path lives inside the same system that already stages your website.

Why the connection point is the failure point

Most teams building agent features spend their effort on prompts and model choice, then treat the data connection as an afterthought. A vector database gets stood up, a sync job copies content into it on some cadence, and an MCP server is written to expose search over that index. Each of those moving parts is a place where production diverges from intent. The sync job lags, so the index reflects content from last Tuesday. The chunking strategy splits a policy mid-clause, so retrieval returns half a rule. The MCP server has no notion of who is asking, so a draft pricing change leaks into an answer before it was meant to publish.

The reason these failures cluster at the connection point is that it is the one component nobody owns as a product. Engineers own the model integration. Editors own the content. The retrieval glue in between belongs to whoever wired it up last, and it inherits none of the discipline applied on either side. There is no staging environment for it, no review step, no audit trail of what an agent was allowed to see on a given day.

Reframing the endpoint as a product surface means giving it the things every other product surface already has: a defined contract, a place to test changes before they ship, observability into what it returned, and access controls that match your content's real states. When the endpoint is native to the content backend rather than assembled beside it, those properties come from the system instead of from a pile of custom scripts you maintain forever.

Freshness is a property of where embeddings live

The single most common production failure in agent retrieval is staleness, and it is almost always architectural rather than accidental. When your embeddings live in a separate vector store, you own a pipeline: detect a content change, re-embed the affected documents, upsert them into the index, and hope nothing fell on the floor in between. Every step in that pipeline is latency, and every cadence you pick is a window during which the agent answers from content that no longer reflects reality.

Sanity Context closes that window by tying embeddings to the content itself. Embeddings are generated against the Content Lake, so when an editor changes a document, the embedding for that document updates within minutes. There is no separate vector pipeline to build, monitor, or reconcile, because the embeddings are not a copy of your content sitting in a second system. They are a property of the content where it already lives.

This is why freshness stops being a project and becomes a default. The retrieval path reads from the same store your editors write to, so the gap between publish and retrievable collapses to the time it takes to compute one embedding. For agents that answer questions about prices, policies, availability, or anything else that changes, that difference is the difference between an answer that is correct now and one that was correct at the last sync. The endpoint, as a product surface, inherits the freshness guarantee of the backend behind it rather than depending on a job you have to keep alive.

Hybrid retrieval belongs in the query, not the glue

Semantic search alone is a known liability for factual agents. Embeddings are excellent at finding conceptually related passages and unreliable at exact matches: a part number, an SKU, an error code, a specific policy name. Pure vector search will happily return something that means roughly the same thing as what the user asked, which is precisely the behavior that produces confident wrong answers. The fix is hybrid retrieval, blending semantic similarity with keyword matching so that exact tokens still anchor the result.

The question is where that blend happens. In a vector-DB-plus-glue stack, you run a semantic query against one system, a keyword query against another, and reconcile the two scores in application code you wrote and now own. That reconciliation logic is fragile, hard to test, and invisible to anyone reviewing the content side.

With Sanity Context, hybrid retrieval is native to the Content Lake and expressed in a single GROQ query. You combine `text::semanticSimilarity()` for the vector side with a BM25-style `match()` for the keyword side, then blend them with `score()` and `boost()` to tune how much each signal counts. One query, one system, one place to reason about why a given document ranked where it did. Because the query is GROQ against the same store that holds your content, the people who model the content and the people who tune retrieval are working in the same language against the same data. The endpoint exposes a retrieval behavior you can read, version, and explain, not a scoring heuristic buried in middleware.

Staging an agent the way you stage a website

When you change your website, you do not edit production directly and hope. You stage the change, preview it, get it reviewed, and release it on a schedule. Agent behavior deserves the same treatment, and almost nothing in the typical RAG stack provides it. Changing what an agent knows, or how it is instructed to behave, usually means editing a config file or a prompt string and pushing it, with no preview of the consequence and no way to roll it back cleanly.

The instructions that govern an agent, the documents it is allowed to retrieve, and the behavior you expect from it are all content, and they belong under the same editorial controls as everything else you publish. In Sanity, editors govern agent instructions inside the Studio, and Content Releases let them stage and schedule changes to that behavior the same way they stage a site launch. A revised set of agent instructions can be drafted, reviewed, and held for release alongside the product update it depends on, then go live together.

This is the pillar of modeling your business showing up in practice: the agent is not a separate system with its own opaque configuration, it is part of the content operation, governed where the content is governed. Roles and Permissions decide who can change agent behavior, Content Releases decide when the change ships, and Audit logs record what changed. The endpoint as a product surface means the thing your agent connects to reflects a reviewed, staged, releasable state of your content, not whatever happened to be in a config repo at deploy time.

Knowledge Bases turn unstructured sources into governed documents

Real enterprise knowledge is rarely all in one clean schema. It is scattered across product data in your CMS, support tickets in a database, PDFs of policies and manuals, and pages on your own website. The naive approach is to build a separate ingestion pipeline for each source, embed everything into one vector index, and lose all provenance and governance in the process. Once a PDF is shredded into chunks in a vector store, you can no longer tell an editor which document a bad answer came from, let alone fix it at the source.

Knowledge Bases address this by turning datasets, websites, PDFs, and support databases into agent-readable documents that share the Sanity Context retrieval path. Instead of a parallel index with its own rules, those sources become documents in the same Content Lake, queried with the same GROQ, governed with the same permissions, and kept fresh with the same dataset embeddings. Provenance survives, because the agent-readable document is a first-class object you can inspect, edit, and release.

That consolidation is what makes the endpoint a single coherent surface rather than a federation of indexes. An agent connecting through the Sanity Context MCP endpoint queries one retrieval path across structured content and ingested unstructured sources alike. This is the shared-foundation argument made concrete: legacy approaches create a silo per source and a glue job per silo, while a Content Operating System gives every source the same retrieval, governance, and freshness model so the agent sees one consistent body of knowledge.

The endpoint your agents actually connect to

All of the preceding properties have to terminate somewhere an agent can reach. That somewhere is the Sanity Context MCP endpoint, the interface production agents connect to in order to query your content. Because MCP is the emerging standard for how agents access tools and data, exposing your governed content through it means the same agent runtime that talks to other tools can ground its answers in your content without a bespoke integration per model.

What makes this a product surface rather than a raw API is everything behind it. The endpoint inherits the freshness of dataset embeddings, the precision of hybrid GROQ retrieval, the governance of Studio and Content Releases, and the breadth of Knowledge Bases. When an agent queries it, it is querying a reviewed state of your content, scoped by the permissions you set, returning results you can trace back to a document. Agent Actions extend the same surface from read to write, exposing schema-aware APIs for LLM-driven workflows like generate, transform, and translate, so the agent operates content rather than only reading it.

Treating the endpoint as a product means you can version its contract, observe what it returns, stage changes to its behavior, and revoke access when you need to. The alternative, an MCP server hand-written over a vector index someone keeps in sync, gives you none of that for free and all of it as ongoing maintenance. The point of Sanity Context is that the endpoint is the visible edge of a system that already does freshness, retrieval, and governance, so the surface your agents depend on is one you can actually own.