No longer maintained
Why this is deprecated
Strapi ships its own MCP server now. A third-party bridge that exists to expose the same content API stops being worth maintaining the moment the platform does it, and a first-party integration will track internal changes more closely than an outside package can.
The security model was a genuine difference, not a vanity feature. Strapi authenticates with a static admin token: no expiry, no rotation, no per-session identity. This ran every call as a specific user with short-lived rotating tokens, reuse detection, an audit trail, and drafts-only writes. What killed it was not that the gap was imaginary, it was that one unmaintained person cannot responsibly own an OAuth server in other people’s dependency trees, and token scoping is an obvious thing for Strapi to add themselves.
It cannot come back as a plugin either. Strapi’s MCP server lets a plugin register tools through strapi.ai.mcp, but authentication is core and there is no seam for wrapping a different token model around it. Upstream is the only route that work survives.
Use the official server. This page stays up because the design is still worth reading, particularly the PKCE flow and the decision to inherit the permission model rather than invent one.
Overview
What it is
The package turned a Strapi instance into an MCP server, so agents like Claude Code and Cursor could work with CMS content directly instead of being told about it.
It read the content types and fields of the running instance at connection time and exposed them as tools, so the tool surface always matched the actual site rather than a schema compiled in at build time.
Motivation
Why I built it
I was copying content between a Strapi admin and a coding agent by hand, which is slow and exactly the kind of thing that should not be manual.
MCP had just landed and I wanted to build something real against it while the spec was still fresh. Learning a protocol properly means implementing it, not reading about it.
Decisions
How it works
PKCE instead of a long-lived token
An agent is a public client with nowhere safe to keep a secret. PKCE protects the code exchange, tokens expire, and a refresh token carries long sessions. Handing an agent a permanent API token would have been easier and considerably worse.
Inherit Strapi permissions, do not rebuild them
Every call ran as the authenticated user, so an agent could do exactly what that role could do. A parallel permission system would have needed to stay in sync with the real one forever, and would have been wrong the first time they diverged.
Drafts as the only write path
Writes created or updated drafts and never published. Given how confidently an agent will produce plausible nonsense, keeping a human between it and live content was not a hard call.
Friction
What was hard
Errors that mean nothing to a model
A bare 403 gives an agent nothing to act on, so errors were rewritten into plain explanations like "your role cannot update this content type". Getting an agent to self-correct rather than retry the same call was most of that work.
Schemas competing for the context window
A large Strapi instance has a lot of content types, and every tool schema shares space with everything else the agent is holding. Keeping the surface lean enough to be usable on a big site was a constant trim.
The state of it
Where it stands
The limitations, in plain terms. Every project here is something I built and use, not something I am selling.
Stack
Deprecated. Strapi ships this natively now and you should use theirs.
It had a small user base, mine included, before Strapi shipped their own.
The per-user OAuth model is still something Strapi’s native server does not do. I think that gap is worth closing upstream rather than in a competing package.
Next project