Anthropic released the Model Context Protocol in late 2024. By mid-2026, at least two headless CMS vendors, Webiny and Strapi, had shipped MCP servers as first-class product features. That changes what "developer experience" means in a CMS evaluation. If your team plans to build with Claude, Cursor, or ChatGPT in the loop, the criteria that mattered a year ago aren't the ones that will decide the outcome now.
This checklist is organized around what actually differs between platforms once agents are writing the code. Each item is stated as something you can verify against a vendor before signing anything. Where Webiny appears, check the claim against the docs linked. Don't take it as a given.
1. Does the platform ship an MCP server, and what does it expose?
MCP standardizes how AI agents discover capabilities, exchange context, and invoke tools. It's built on JSON-RPC 2.0 with stateful session management, and it's what lets an assistant in Claude or Cursor read your content schemas, query repositories, create entries, and trigger workflows through one governed interface.
Two things to check.
Where the server runs. Webiny ships a local MCP server that runs entirely in your environment, so no project data leaves your infrastructure. Strapi's MCP server, GA in v5.49.0 (July 2026), authenticates via Admin API tokens and exposes CRUD tools per content type: find, create, update, publish, unpublish. These are different kinds of MCP server. Webiny's carries platform knowledge to the agent. Strapi's exposes runtime content operations to the agent. A serious evaluation asks for both.
What the server actually gives the agent. Webiny's MCP server provides structured skills, focused guides on content models, lifecycle events, dependency injection, and infrastructure, so the agent works from current, platform-specific knowledge rather than whatever it absorbed during training. Ask any vendor claiming MCP support whether the server exposes tools, knowledge, or both. Ask to see the skill list.
MCP support alone is no longer a differentiator. What the server exposes, and where it runs, is.
2. Is the schema defined in TypeScript, and does the type system reach the agent?
Strong typing is the most reliable hallucination check available. When an agent generates code that violates type constraints, the TypeScript language server flags it immediately. No deployment, no runtime failure, no silent bug shipped to production. Developers building with AI report that the type system does most of the correction work on its own.
For a CMS, the question is whether that feedback loop reaches your content layer. If your content types are defined in a database GUI, the agent has no way to know their shape until it queries them at runtime. If they're defined in TypeScript, colocated with application code, the agent sees them the same way your IDE does.
Payload defines content types in TypeScript alongside application code, and its Local API removes the network hop for server-side rendering, both properties that reviewers cite as making AI-generated code easier to trust. Webiny is TypeScript-native across its framework, CMS, and Website Builder.
If the schema lives outside your type system, the agent is guessing. Ask each vendor to show you a content type definition and trace where the type flows.
3. Can you build a working integration from the documentation alone?
This is the oldest criterion on the list and still the most predictive. Documentation quality determines whether developers trust the platform enough to expand use cases and recommend it internally. The test hasn't changed: during your proof of concept, build a working integration straight from the docs and see how far they carry you before you have to open a support ticket.
What's changed is that the docs are now also training data, for your agent, in-session, via MCP or via retrieval. Sparse or outdated documentation degrades agent output the same way it degrades developer output, only faster and less visibly. Check the docs' last-updated dates. Check whether code examples match the current major version. Check whether the vendor exposes docs to agents as structured content or as scraped HTML.
Documentation quality is now doing double duty. Evaluate it for humans and for the agent that will read it a hundred times a day.
4. Where does the CMS run, and does that constrain who can adopt it?
An AI-accelerated development workflow doesn't matter if the platform can't be deployed inside your compliance perimeter. This is where self-hosted, open-source CMS platforms diverge sharply from SaaS.
Webiny runs serverless on AWS or in your own containerized environment. On AWS it's serverless (Lambda, DynamoDB, S3, CloudFront), so there are no servers to patch and it scales with traffic. Webiny can now also be deployed in containerized environments such as Docker and Kubernetes, giving teams greater flexibility in how they run and manage their Webiny deployments.
For SaaS platforms like Contentful and Sanity, the question is different: what data crosses the vendor boundary, and can your MCP-connected agent be scoped so it doesn't exfiltrate content it shouldn't touch?
Deployment model is a hard filter. Confirm it before you evaluate features.
5. Does the platform handle multi-tenancy natively, or will you build it?
If you're running more than one brand, region, or customer-facing property from one CMS instance, multi-tenancy is either built in or it's a project on your roadmap. Building it yourself on top of a single-tenant CMS is measured in quarters, not weeks. It's also exactly the kind of foundational work AI agents are worst at, because it touches auth, data isolation, and infrastructure simultaneously.
Webiny includes native multi-tenancy via its Tenant Manager, designed for running many web properties from a single instance. Most other open-source headless CMS platforms treat multi-tenancy as an application-layer concern you implement yourself.
If multi-tenancy is on your requirements list, treat it as a binary vendor filter, not a feature comparison.
6. What does the license-plus-hosting economics look like at your scale?
SaaS CMS pricing scales with entries, API calls, users, or locales, sometimes all four. Self-hosted, open-source CMS pricing scales with your infrastructure bill plus whatever license tier you need for enterprise features (SSO, audit logs, RBAC).
Webiny's Community Edition is MIT-licensed and free. Business Edition starts around $79/month for RBAC, multi-tenancy, and publishing workflows. Enterprise is custom. Model both curves at your projected 24-month scale before deciding. The crossover point is often earlier than SaaS vendors' pricing pages suggest.
Run the numbers at your real scale, not the vendor's example scale.
7. Does the vendor publish honest limits, or only capabilities?
A proof-of-concept implementation typically takes three to six months and rarely ships on the first iteration. If a vendor's marketing suggests otherwise without publishing the constraints, treat that as a signal.
Look for known limits documented in the docs, not buried in a forum, a public changelog with dated version entries, and version-tagged code examples. Vendors that publish their limits are the ones whose agents will have accurate context to work with. Vendors that don't will have agents confidently generating code against features that don't exist.
Transparency about limits is a leading indicator of documentation quality, which is a leading indicator of agent output quality.
Frequently asked questions
What is an AI-accelerated CMS?
An AI-accelerated CMS is a content platform designed so AI coding agents can build against it productively, typically via an MCP server that exposes either platform knowledge, runtime operations, or both to assistants like Claude, Cursor, and ChatGPT. The term is newer than the underlying idea. Any CMS with strong typing, good docs, and a clean API has always been friendlier to AI-generated code. What's changed is that vendors are now shipping first-class agent interfaces rather than leaving developers to build them.
Is MCP support enough to call a CMS "AI-ready"?
No. MCP is a protocol. What matters is what the server exposes and where it runs. Two vendors can both claim MCP support and offer very different things: one might expose CRUD tools per content type, another might carry structured platform knowledge to the agent. Ask to see the tool list and skill list before treating MCP as a checked box.
How does Webiny compare to Strapi and Payload for AI-accelerated development?
All three are TypeScript-based, open-source, self-hostable, and ship or integrate with MCP. The meaningful differences are architectural. Webiny includes native multi-tenancy via its Tenant Manager and ships a local MCP server carrying structured skills about its own APIs and patterns. Strapi's MCP server (GA in v5.49.0) exposes content types as agent-callable CRUD tools. Payload's differentiator is a TypeScript-native schema colocated with application code and a Local API that removes a network hop. Which one fits depends on whether your priority is multi-property governance (Webiny), runtime content operations from the agent (Strapi), or the tightest possible TypeScript feedback loop (Payload).
What should I ask a vendor in a demo?
Ask to see a content type defined and used in a working project, the MCP server running against that project with an agent invoking at least one non-trivial tool or skill, the deployment target and what it requires, the documentation's last-updated date on a page you care about, and a customer at roughly your scale. If any of these can't be shown live, treat the gap as data.
