MCP for Content Teams: What the Model Context Protocol Means for Your CMS

The Model Context Protocol is quietly reshaping how software connects to data. If you work in content operations and have not heard of MCP yet, you will soon. Every major AI framework, from Anthropic’s Claude to tools like Cursor and the Vercel AI SDK, now supports MCP as a standard way for AI agents to query external systems.

This means your CMS is no longer just a backend for websites. It is potentially the knowledge layer for every AI agent in your organization, from customer-facing chatbots to internal research assistants to automated content workflows. The question is whether your current CMS can participate. Most cannot. A Content Operating System is built for this from day one.

MCP in Plain Language

Think of MCP as a universal adapter between AI agents and data sources.

Before MCP, every integration was custom:

• If you wanted your support bot to read your CMS, you built a custom API integration.
• If you wanted a different agent to read the same CMS, you built another integration.

MCP standardizes this. You expose an MCP endpoint, and any compatible agent can connect, discover what tools are available, and start querying. It is the difference between every device needing its own proprietary charger and everyone agreeing on USB-C.

For content teams, this means you configure your CMS once and every AI tool in your stack can access your content through the same protocol.

Why Most CMSes Cannot Speak MCP

MCP requires the backend to expose structured, queryable data through discoverable tools.

Legacy CMSes store content as HTML blobs tied to page layouts. If you point an MCP server at this data, the agent receives a mess of presentation markup mixed with actual content.

Standard headless CMSes are better because they deliver JSON via APIs, but their query languages are often too limited for agents to express complex requests. An agent that needs all products in the outdoor category under 200 dollars with positive inventory in the EU region needs expressive filtering, projection, and reference traversal in a single request.

Most headless CMS APIs require multiple round trips and custom middleware to achieve this. The CMS must treat content as structured data with an expressive query language to make MCP useful.

Agent Context as Your MCP Endpoint

Sanity’s Agent Context is a hosted MCP endpoint purpose-built for production agents.

When an agent connects, Agent Context provides three tools:

• initial_context gives the agent a compressed overview of your schema, document types, fields, and content volume.
• schema_explorer lets the agent inspect any type in detail.
• groq_query lets the agent execute arbitrary GROQ queries against your Content Lake.

This means any MCP-compatible agent can connect to your Sanity project and immediately understand your content model, discover what content exists, and query it with the full power of GROQ. The agent can filter, project, join references, and apply hybrid search combining BM25 keyword matching with semantic embeddings, all in a single request.

What This Means for Content Teams

The practical impact for content operations teams is significant:

• Your product documentation becomes the knowledge base for a customer support agent without building a RAG pipeline.
• Your marketing content becomes accessible to an editorial copilot that helps writers find approved messaging.
• Your product catalog becomes queryable by a shopping assistant that checks real inventory.

All of these agents connect to the same MCP endpoint, governed by the same access controls, reading from the same source of truth. When your team publishes an update, every connected agent reflects the change.

You do not manage separate data pipelines for each AI application. You manage your content in Studio and the agents handle the rest.

Governance and Control

Opening your content to AI agents raises legitimate governance concerns. Agent Context addresses these through scoped access.

You create Agent Context documents in Studio that define what each agent can see:

• A customer-facing bot might be restricted to published support documentation.
• An internal research assistant might have broader access to marketing and product content.
• A developer tool might access the entire schema but only published documents.

Each Agent Context configuration generates a unique MCP URL with its own access scope. You manage these configurations in Studio alongside your content, not in a separate infrastructure layer. Combined with API read tokens, you maintain full control over which agents access which content.

The Bigger Picture

MCP adoption is accelerating across the AI ecosystem. As more tools support the protocol, the value of having your content accessible through a standards-compliant MCP endpoint compounds.

Early adoption means your content is ready for agent integrations that have not been built yet. Teams that wait will find themselves building custom middleware to retrofit their CMS for every new AI tool. Teams that adopt Agent Context now position their content as a first-class participant in the agentic web.

{
  "tool": "groq_query",
  "arguments": {
    "query": "*[_type == 'product' && category == 'outdoor' && price < 200 && inventory[region == 'eu'].inStock == true]{name, price, 'regionInventory': inventory[region == 'eu'][0]{region, inStock}}"
  }
}