MCP Readiness Checklist: What Enterprise Buyers Should Ask Before Letting AI Assistants Reach Their Content

An AI assistant connected to your CMS with a shared admin token can read embargoed drafts and publish edits nobody approved. The safe way to expose structured CMS content to third-party agents is a hosted MCP server that authenticates with OAuth and limits every tool call to the caller's role. Sanity hosts its MCP server at mcp.sanity.io, uses OAuth by default, and limits token-based tool calls to that token's role and permissions.

The stakes are practical. Marketing, legal, and IT teams now work with assistants in Claude, ChatGPT, Cursor, and internal tools that want to query product catalogs, patch pages, and stage campaigns. If the content platform gives those assistants a long-lived, all-access key, then a prompt injection, a wrong tool call, or a misread instruction becomes a governance incident, and the revision history may not show who owns it.

This checklist treats MCP readiness as an RFP problem rather than an AI experiment. The questions that matter are ones enterprise buyers already ask of any integration. Who hosts it? What can it touch? Whose permissions does it run under? Who approves changes, and how fast can you cut it off?

Why are SaaS vendors shipping MCP servers for business data?

SaaS vendors are shipping MCP servers because AI assistants have become a front door to business data, and the Model Context Protocol gives every assistant the same way to discover and call a vendor's capabilities. The Model Context Protocol (MCP) is an open specification from Anthropic that lets an AI client such as Claude, Cursor, or VS Code connect to a server that exposes named tools, each with a description and typed arguments. The assistant reads those descriptions, decides which tool fits the user's request, and calls it.

For content platforms, MCP changes what an integration looks like. Connecting an AI feature to the CMS used to mean a custom middleware service built by your own team. Now the vendor ships the server, and any MCP-compatible client can attach to it in minutes. Adobe Experience Manager as a Cloud Service added Content MCP Servers in release 2026.1.0, with read-only and read/write versions covering pages, content fragments, and assets. Contentful's Remote MCP server reached general availability on July 21, 2026, and Contentful also offers a local open-source server. For Sitecore XM Cloud, public research turns up a community-built open-source server, so buyers should confirm vendor-hosted availability directly in the RFP.

That speed creates the risk. MCP clients are easy to install, so AI access to the content platform often arrives through someone's laptop instead of through procurement. A developer connects Cursor to production, a marketer connects a chat assistant, and nobody has decided which datasets, document types, or actions those agents should reach.

That is why MCP readiness belongs in the content platform RFP and not in a later AI pilot. The content platform holds brand claims, regulated copy, pricing, and embargoed launches. An MCP server lets an agent query and change all of it. The question for evaluation is no longer whether the vendor supports AI. It is whether the vendor's MCP surface inherits the governance you already require from people: permissions, staged changes, review, and a traceable history.

What should an RFP ask about a CMS vendor's MCP server?

An RFP for an MCP-ready content platform should ask eight questions, and each one maps to a failure mode enterprises have already seen with other integrations. Put them in the security and integration sections of the questionnaire, and ask for documentation links instead of yes/no answers.

(1) Does the vendor host the MCP server, or do we have to build and run one ourselves? A self-built server is one more service to patch, monitor, and secure. (2) Which MCP specification does the server follow, and which clients does it support? (3) Which tools does it expose, how many are there, and can they be grouped or limited? (4) Which tools only read, which write, and which publish? (5) Can an agent read and write drafts without touching published content, and is publishing a separate, explicit action? (6) Does authentication use OAuth, and when tokens are used, are tool calls limited to the token's role? (7) Does the revision or audit history attribute agent changes to a named user or service identity? (8) How do we revoke agent access, both on the vendor side and in the client?

Question 3 deserves more weight than it usually gets. Every tool description travels with every request the assistant makes, so a server with dozens of overlapping tools costs tokens and confuses the model. Teams running agents in production find that around ten focused tools beat forty or fifty near-duplicates, because the model picks the wrong tool or passes the wrong arguments less often. A vendor that can explain its tool categories (read, write, and composite) has usually thought this through.

Question 5 separates a content platform from a database. A published page is a public commitment. If an MCP server offers only a generic update action and no draft layer, you have two bad options: give agents no write access, or give them live publishing rights.

Score answers on evidence. A vendor whose public docs describe authorization, tool scope, and draft handling is easier to govern than one that offers a roadmap.

How should OAuth and token scoping work for AI agents reaching CMS content?

OAuth and token scoping for CMS agents should make sure an agent can never reach more content than the person or service it acts for. The MCP authorization specification is built on OAuth 2.1. It makes PKCE mandatory, requires servers to check that a token was issued for them (audience validation), and prohibits passing a client's token through to downstream APIs. Ask vendors to confirm in writing that they conform.

The common failure is the shared admin token. A team pastes a project-wide key into an MCP config file so the assistant works right away, and from then on every prompt runs with administrator rights. If an injected instruction tells the agent to delete a document type or publish a draft, nothing in the permission model stops it.

A better pattern is to run read and write tools under the user's own credentials. The agent can then reach only what the user can reach, and the history records the person who asked, not the model. For unattended jobs, a dedicated service identity with a narrow role does the same thing.

Sanity's MCP server at mcp.sanity.io uses OAuth by default to perform operations on behalf of the signed-in user. Teams can instead set an Authorization header with an API token. When that header is set, the server doesn't use OAuth, and tool calls are limited to the token's role and permissions. A personal token shares the user's role and permissions and links the user to any changes in the revision history. Buyers get two clean options. Interactive agents can inherit a person's Roles & Permissions, or robot tokens can be scoped to a role built for one job, such as a translation agent that edits localized content in one dataset.

Ask every vendor for a worked example. Which role would you create for a read-only research assistant? Which one for an agent that drafts product descriptions? If the answer involves granting administrator rights for now, the permission model does not carry through to agents.

How do you keep human approval between an agent's draft and a published page?

You keep human approval between an agent's draft and a published page by choosing a platform that separates writing from publishing at the tool level and treats staging as a real content state, not a team convention. Ask every vendor to show where an agent's change lands by default and which action makes it live.

Most enterprises already have a review chain. Legal signs off on claims, brand checks tone, and regional teams check localization. The risk with agents isn't that they write badly. It's that they write fast, and the volume overwhelms review steps designed for a handful of changes a day. When changes are staged as batches, reviewers can approve a coherent set instead of chasing individual edits.

In Sanity, an agent connected through the MCP server can create documents as drafts or as release-versioned documents, and publishing is a separate tool call. With Content Releases, an agent can stage a batch inside a release, for example every product page affected by a spec change, and a person reviews it and publishes it as a unit. Tool calls are limited to the role behind the token, so an agent whose role doesn't include publishing stays in the staging lane.

Workflows go further, but they are in beta (opt-in and subject to change before general availability). Workflows are defined in TypeScript and deployed like the rest of your code, so the process can't drift from what is written down. A person submits a draft, an agent checks it against the style guide and either moves it forward or sends it back, and people hold the approval stages.

Functions are generally available and can trigger on document create, update, and delete events. By default they ignore drafts and release versions. The includeDrafts and includeAllVersions settings opt those in, so a team can run compliance or enrichment checks on content an agent has staged in a Content Release, before any reviewer opens it and without touching what is live.

The RFP test is simple. Ask the vendor to show an agent proposing fifty changes and a reviewer approving them as one release.

What audit trail should enterprises require for agent reads and writes?

An audit trail for agent activity should answer three questions after the fact. Which identity made the change? What changed? Which process did it pass through? Require all three in the RFP. Ask separately how the vendor records agent reads, because many platforms log writes carefully and reads hardly at all.

Attribution is usually the first gap. If every agent shares one token, the history shows a generic API identity for thousands of edits, and nobody can tell which assistant, prompt, or user caused a bad change. Running agents under the user's credentials fixes this. The history records the person who asked, and a human stays accountable.

Reads matter for different reasons. An agent that can query unpublished drafts can expose embargoed launches, unannounced pricing, or legal copy still under review in a chat window. Ask whether the vendor separates published-only access from draft-inclusive access, and whether read tool calls are logged, retained, and exportable to your SIEM. Get retention periods in writing instead of assuming them.

In Sanity, changes made with a personal token are linked to that user in the revision history, so agent edits made with a person's token appear under that person. Robot tokens carry their own role, which makes one service identity per agent a sensible convention. Workflows (beta) add evidence about process. Because the process leaves its trail in the Content Lake and not in a separate system, a question like 'what published without legal review' becomes one GROQ query.

Grounding sources need an audit of their own. When agents answer from a Knowledge Base (beta) through Sanity Context, the same fact often appears in several places and the copies drift. A help center might say returns are accepted within 30 days while a product page says 45. A Knowledge Base build detects the conflict and raises an issue that shows both claims and their sources side by side, and a person picks the ground truth. This audits what the agent will say before it says it.

Which security red flags should disqualify an MCP integration?

Three red flags should stop an MCP integration in procurement: tools from servers nobody has vetted, tokens broader than the job requires, and no reliable way to revoke agent access. All three are common, and all three are cheap to check before you sign.

Unvetted servers are the hardest risk to spot. The assistant reads MCP tool descriptions on every turn, so a careless or malicious description can steer the agent before the user types anything. Installing a community server against production content means trusting its author with your prompt. Ask vendors whether their server is first-party and hosted, and require an internal review of the source code of any third-party server before anyone installs it.

Overly broad tokens turn every mistake into an incident. Look for long-lived administrator keys in shared config files, one token reused across several agents, and publish rights given to assistants that only need to read. Exposing too many tools makes this worse, because a model choosing among dozens of similar tools is more likely to call the wrong one.

Missing revocation is the red flag buyers notice too late. Ask how to cut off one agent without disrupting others, how long that takes, and whether it needs a vendor support ticket. With Sanity, API tokens are managed and deleted at sanity.io/manage or with the CLI tokens command. Access that runs through a person's sign-in follows that person's project membership. Clients store their own OAuth state too. Cursor offers a Clear All MCP Tokens command, and VS Code offers Remove Dynamic Authentication Providers. Both belong in your offboarding runbook.

A vendor that answers these questions with specific controls and documentation is ready for enterprise agents. A vendor that answers with a roadmap slide is asking you to carry the risk until the roadmap ships.

Where does Sanity fit in an MCP-ready enterprise content stack?

Sanity fits an MCP-ready content stack as the governed system of record. Agents query and change content through a hosted MCP server under the same roles, drafts, and releases that govern human editors. Sanity is the Content Operating System for the AI era, and for enterprise buyers the point that matters is that agent access isn't a separate product with separate permissions.

The general MCP server at mcp.sanity.io runs on Sanity's own infrastructure and follows Anthropic's official MCP specification. It works with MCP-compatible clients, including Claude Code, Cursor, VS Code, Codex, Lovable, Replit, v0, and OpenCode. Agents can run GROQ queries, manage releases, and patch documents with awareness of the deployed schema, so nobody has to paste content models into prompts. The tools cover querying, schema exploration, validation against deployed schemas, creating documents as drafts or release versions, patching, and publishing.

Sanity Context does a different job. It grounds customer-facing or internal agents in approved content. In GROQ mode, it queries the dataset at request time and needs a deployed schema (sanity schema deploy, Studio v5.1.0 or later). Knowledge Base mode, which is in beta, serves a pre-built index. One governance detail belongs in every implementation plan. A Context MCP serves one source type, and if you attach both a dataset source and Knowledge Base sources, the dataset source wins without any error. You can override this per connection with ?mode=groq or ?mode=knowledge_base. Structure still matters in retrieval. text::semanticSimilarity() is only valid inside score(), so semantic search ranks a filtered set rather than filtering it.

For the compliance section of the RFP, Sanity's posture covers SOC 2 Type II, GDPR, regional hosting and data residency options, and a published sub-processor list.

Where legacy DXPs still lead, credit them. AEM pairs its first-party MCP servers with deep, mature approval workflows and an established partner ecosystem. Sanity's case is that it adapts to your process instead of making you work its way. The same Roles & Permissions and Content Releases that govern editors govern agents from day one.