Sanity MCP Updates: Safer Content Writes, With a Schema Catch
An agent that can edit a CMS needs more than a working connection. Before giving it a publishing job, ask what stops a malformed write and what happens when the server cannot perform that check.
Sanity’s October 28 MCP server release, v2.45.0, validates document creates, patches, and publishes against a deployed schema when it can identify one unambiguously. Invalid mutations are blocked. But if schema selection fails, the mutation proceeds with a warning. Projects without a deployed schema proceed without that warning. Those exceptions are part of the documented behavior, not an edge case to assume away. See the October 28 release notes.
Our read: this is a useful improvement for content agents, but not a reason to remove your own preflight checks. This article analyzes the release notes; it is not a hands-on test of the hosted service.
Validation is conditional, not a blanket guarantee
The important distinction is between a mutation that passes validation and one that continues without it. Sanity’s release notes describe both paths. They also document handling for liveEdit document types: creates and patches target published IDs directly rather than leaving incompatible drafts. That deserves its own review if your workflow assumes every edit first lands in a draft. Source: v2.45.0.
For a production content agent, we would make schema availability a prerequisite rather than treating a successful write response as proof that validation happened. Before a batch job, establish:
- Which project and dataset the job may change.
- Which deployed schema should govern those changes.
- Whether schema selection is unambiguous.
- Whether the target document type uses a draft workflow or live editing.
- What the agent must do when a validation warning appears.
Our recommended default is to stop for review when the expected schema cannot be established. That is an application policy, not a claim about Sanity’s default behavior.
A patch guardrail worth testing
An earlier release, v2.42.2 on October 26, fixed deployed-schema validation so built-in checks, including slug structure and uniqueness, run correctly. It also changed patch_documents to reject patches that would change or remove a document’s _type. The release notes describe a common cause: putting an object value at the document root instead of beneath its intended field. The rejected patch writes nothing and returns corrective guidance. Source: October 26 fixes.
That gives developers concrete regression cases. In a disposable dataset, test a valid field update, an invalid slug, and a root-level object patch that would disturb _type. Inspect the stored document after each attempt, not just the tool response. Record the expected result before running the test so a plausible-looking response cannot become the acceptance criterion.
Do not intentionally run destructive test cases against production content. Our local MCP testing guide covers the broader connection-testing workflow.
OAuth discovery is a separate concern
On October 29, Sanity released v2.45.2 with an OAuth-discovery fix. Documentation redirects are now limited to browser navigation and requests for HTML or Markdown. That is the scope of the published fix; it does not announce new permissions or a different approval model. Source: October 29 release notes.
Treat connection testing and mutation testing as separate acceptance gates. First confirm the intended client can discover and authenticate to the service. Then confirm the connected account has the intended boundaries. Only then exercise content writes in a test environment.
A login completing successfully should not be your evidence that the agent can safely publish. For the distinction between connection authorization and workflow policy, start with how MCP auth works.
What this means when choosing a CMS integration
Sanity MCP is already listed in AgentNDX. Use that listing for discovery, then check the upstream release notes for the behavior your workflow depends on. We are not asserting that a directory install command delivers the same deployment described by the hosted service’s changelog.
When evaluating any content-writing integration, ask for specific answers rather than a general safety label:
| Question | Evidence to request |
|---|---|
| What validates a write? | Named schema and a rejected invalid-write test |
| What happens without that schema? | Observed warning or failure behavior |
| Does an edit affect live content? | Document lifecycle and target ID |
| Can the job publish? | Explicit account permissions and approval policy |
| Did the intended change land? | Read-back of the exact document and fields |
Our recommendation is to keep publication approval separate from document validation. A structurally valid change can still be the wrong price, an unapproved claim, or an edit to the wrong page. The release notes establish narrower technical protections, not editorial judgment.
FAQ
Does Sanity MCP now block every invalid content write?
Not as a blanket guarantee. The October 28 notes make validation conditional on identifying a deployed schema. They document continuation paths when schema selection fails or no schema is deployed. Source: mutation validation behavior.
Does the OAuth fix make publishing safer?
The October 29 entry documents a discovery-related redirect fix, not a publishing safeguard. Test authentication separately from content validation and approval. Source: OAuth discovery fix.
What should a team test before enabling content writes?
We recommend a disposable-dataset test covering connection, schema selection, valid and invalid patches, draft versus live behavior, and exact-document read-back. Keep the production job blocked until its expected outcomes are explicit and verified.