How to Connect Claude to Your Internal Content via MCP and Sanity Context

Your team wires Claude into a support workflow, and within a day it confidently cites a refund policy that was retired eighteen months ago. Nobody typed that policy into the prompt. The model pulled it from a stale document that a naive retrieval layer surfaced with high confidence, and now a customer is holding you to a promise you never made. This is the failure mode that kills internal AI rollouts: not that the model is dumb, but that it is grounded in the wrong content, retrieved without governance, with no way to trace where an answer came from.

The fix is not a better prompt. It is a better connection between the model and your real, current, structured content. Sanity Context (previously Agent Context) is the AI Content Operating System layer for exactly this problem: an intelligent backend that lets Claude query your product, support, and documentation content through the Model Context Protocol, grounded in the same Content Lake your editors already govern.

This guide walks through how MCP works, how Sanity Context exposes your content to Claude through its MCP endpoint, how hybrid retrieval keeps answers accurate, and how editors keep agent behavior reviewable instead of loose in a config file.

Why connecting Claude to internal content usually breaks

The typical internal-agent project starts with optimism and a folder of exports. Someone dumps PDFs, wiki pages, and a support database into a vector store, wires Claude to it, and demos a few clean answers. Then reality arrives. The refund policy changed but the embedding did not. Two documents describe the same feature differently, and retrieval surfaces the wrong one. A product name got updated everywhere except the one archived doc that ranks highest for the query. The model is not hallucinating in the classic sense; it is faithfully repeating bad context that a brittle retrieval layer handed it.

There are three compounding problems here. First, the content is unstructured, so the retrieval layer guesses at what a chunk means instead of knowing. Second, the embeddings live in a separate pipeline from the source content, so every edit opens a window where the vector store and the truth disagree. Third, nobody owns the agent's behavior. The instructions that shape how Claude answers sit in a code repository, edited by whoever last touched the deployment, invisible to the content and support teams who actually know what the answer should be.

Enterprise stakes make this worse than an inconvenience. An agent that cites retired policy is a compliance exposure. An agent that contradicts your documentation erodes the trust that made the rollout worth funding. The reframe this guide argues for is simple: the reliability of an internal Claude deployment is a property of how content is modeled, retrieved, and governed, not of the model you picked. Fix the connection and most hallucination symptoms disappear.

How MCP actually connects a model to your content

The Model Context Protocol is an open standard that lets a language model call external tools and data sources through a consistent interface. Instead of stuffing your entire knowledge base into a prompt (which is expensive, lossy, and quickly exceeds any context window), MCP lets Claude ask for exactly the content it needs at the moment it needs it. A client like Claude Desktop or a custom agent connects to an MCP server, discovers the tools and resources that server exposes, and issues structured requests during a conversation. The server does the retrieval and hands back scoped, relevant results.

The distinction that matters for reliability is where the retrieval logic lives. In a bolt-on setup, the MCP server is a thin shim in front of a vector database you populated with a separate ingestion job. The shim can only return what that job happened to embed, and it has no notion of whether a chunk is current, published, or authoritative. Retrieval quality is capped by an ingestion pipeline that ran at some point in the past.

Sanity Context takes the opposite approach. The Sanity Context MCP endpoint sits directly on top of the Content Lake, Sanity's queryable content store. When Claude issues a request, the server runs a real query against live, structured content, not a stale mirror of it. This is the practical payoff of treating your content backend as the retrieval path rather than a source to copy out of. Claude connects to one endpoint, and behind it is the same governed content your editors publish from, shaped as documents the model can actually reason about.

Grounding Claude in structured content with the Content Lake

Structure is what separates a source of truth from a pile of text. When you model content in Sanity, a support article is not an opaque blob; it is a document with a title, a status, a product reference, an effective date, and a body in Portable Text. That structure travels with the content into retrieval. Claude does not just get "some text that seemed relevant"; it can be handed the current, published version of the exact document type that answers the question, with the metadata that lets it reason about recency and applicability.

This is where the difference between a Content Operating System and a generic store becomes concrete. A retrieval layer that only sees flattened chunks cannot distinguish a draft from a published policy, or last quarter's pricing from this quarter's. A retrieval layer built on modeled content can filter to published documents, scope to a product line, and exclude anything past its effective date, all before a single result reaches Claude. The model spends its reasoning budget on the answer, not on untangling which of five contradictory chunks to trust.

Knowledge Bases extend this reach to the content that does not start life in Sanity. Datasets, websites, PDFs, and support databases become agent-readable documents that share the Sanity Context retrieval path, so a Claude agent queries an external support export through the same governed interface as your first-party documentation. The result is one grounding surface for the model instead of a patchwork of connectors, each with its own freshness story and its own way of being wrong.

Hybrid retrieval: why keyword and semantic search both matter

Semantic search is excellent at intent and terrible at specifics. Ask an embedding model about "the return window for opened electronics" and it will find conceptually related passages, but it may float right past the one document that contains the exact SKU prefix or policy code the user typed. Keyword search is the mirror image: precise on exact tokens, blind to paraphrase. An agent that relies on only one of these fails in a predictable half of cases, which is why serious internal deployments blend both.

Most stacks blend them by bolting a vector database next to a search engine and writing glue code to merge two result sets, reconcile two scoring schemes, and keep two indexes in sync. Every one of those seams is a place where relevance degrades and freshness drifts. Sanity Context does the blend natively inside the Content Lake. In a single GROQ query you combine `text::semanticSimilarity()` for meaning with a BM25-style `match()` for exact terms, then shape the ranking with `score()` and `boost()` so a current, published, exactly-matching document outranks a vaguely-related archived one. One query, one ranking, one source.

The freshness angle is the quiet advantage. Because dataset embeddings are tied to the content itself, an edit propagates to retrieval within minutes rather than waiting for the next batch reindex. There is no separate vector pipeline to babysit, no nightly job whose failure silently poisons your agent's answers. When an editor corrects that refund policy, the version Claude can retrieve corrects with it, which is the single most effective hallucination prevention you can deploy.

Governing agent behavior with Studio and Content Releases

Retrieval accuracy is only half of a trustworthy agent. The other half is behavior: what the agent is instructed to do, what tone it takes, which content it is allowed to draw on, and how all of that changes over time. In most deployments those instructions live as string constants in a codebase, changed through pull requests by engineers, entirely opaque to the content and support teams who understand what a correct answer looks like. When the agent goes wrong, the people best equipped to fix it cannot even see the instruction that caused the problem.

Sanity moves agent instructions into the same place editors already work. In Studio, the prompts and content that shape agent behavior are modeled documents, editable and reviewable by the people who own the domain, not just the people who own the deploy. Content Releases let a team stage a change to agent behavior and preview it the way they would stage a website change, so a new support policy and the agent instruction that references it ship together, atomically, rather than drifting out of sync. Agent Actions provide schema-aware APIs for the content workflows an agent runs, so generating, transforming, or translating content happens against your real model instead of freeform text.

Governance also means an audit trail. Sanity carries Roles & Permissions, Audit logs, and Content Source Maps, so you can answer the question every regulated buyer eventually asks: which document produced this answer, who last changed it, and who was allowed to. On compliance, Sanity is SOC 2 Type II audited, supports GDPR obligations, offers regional hosting for data residency, and publishes its sub-processor list.

A reference architecture for a production Claude deployment

Putting it together, a durable internal-Claude setup has four layers, and each one maps to a pillar of how Sanity Context is built. Model your business: content lives in the Content Lake as typed documents, with Knowledge Bases pulling external PDFs, websites, and support databases into the same shape. This is the grounding surface, and its quality ceiling is set here, not at query time.

Automate everything: Claude connects to the Sanity Context MCP endpoint and retrieves through GROQ hybrid queries that blend `text::semanticSimilarity()` and `match()`, filtered to published, current, in-scope documents. Because embeddings are tied to content, this layer stays fresh without a separate pipeline. Agent Actions handle any content the agent needs to generate or transform, running against your schema rather than loose strings.

Power anything: the same governed content serves your Claude agent, your website, your mobile app, and whatever surface comes next, because retrieval and publishing draw on one source rather than diverging copies. Governance wraps all three: Studio and Content Releases keep instructions reviewable and stageable, while Roles & Permissions and Audit logs keep the whole system accountable.

The contrast with the assemble-it-yourself path is stark. The DIY stack is a content store, a separate embedding job, a vector database, a keyword index, merge logic, and a hand-rolled MCP shim, each an independent failure point you now operate. Sanity Context collapses that into one intelligent backend for companies building AI content operations at scale, where the thing Claude retrieves from is the thing your team already governs. Fewer moving parts is not just less work; it is fewer places for your agent to quietly go wrong.