Owners of websites built on Promo Core can now manage their content simply by chatting with an AI assistant such as Claude, ChatGPT or Cursor. There's no need to click through dashboard pages, and the AI never gets more access than the person who connected it.

This article expands on my recent talk about MCP. In it, I explain what MCP is, why we decided to build it into Promo Core, how it works for the admin and behind the scenes in the backend, and how we keep it secure at every step.

What MCP is

MCP (Model Context Protocol) is an open standard that lets AI apps use outside systems as tools. Anthropic introduced it in November 2024, and it quickly became an industry standard. Any AI tool that supports MCP can connect to it: the main ones are Claude, ChatGPT, Cursor and VS Code, alongside others such as GitHub Copilot, Gemini CLI and Windsurf.

On its own, an AI model can only write text. It can draft an article for you, but you still have to copy it into the dashboard yourself. MCP lets the AI take real actions instead, like creating that article as a draft in our CMS.

The three players

Each tool has a name (like create_article), a plain-English description, and the inputs it expects. The model never sees our code. It only reads those descriptions and picks the right tool, so writing good descriptions is a big part of the work.

MCP is used well beyond CMSs: developers connect it to repositories and CI, companies connect it to Jira, Slack and Notion, and support teams use it to fetch tickets and draft replies. Our use case is content management.

Why we built it into Promo Core

We gave our CMS a new interface, not a new backend. Four reasons drove it:

• Faster content work. Admins describe what they want in plain language ("add a FAQ about delivery times in English and Arabic") instead of filling in forms field by field.
• Same data. The AI goes through the same NestJS services as the dashboard, so there is no second system to maintain and nothing gets out of sync.
• Same permissions. The AI acts as the admin who connected it, never as a super-user. It can only do what that admin can do in the dashboard.
• Every client gets it. Promo Core is a white-label starter that we copy for each client, so every new client project ships with an AI-ready CMS out of the box.

How it works for the admin

Connecting takes about a minute and happens once. After that, the admin just talks to the AI.

1. Connect. The admin adds a new connector in Claude or ChatGPT and pastes our MCP URL. The dashboard's Connectors page shows that URL, with a step-by-step guide for Claude, ChatGPT and Cursor. When Claude first tries the server, our backend answers "not authorized" and tells it where to log in.
2. Consent. Claude opens our dashboard's consent page. The admin logs in with their normal Promo Core account, sees which app is asking for access, and clicks Approve. It is the familiar "Sign in with…" pattern (the standard behind it is OAuth), so the admin never gives their password to Claude or ChatGPT.
3. Token. Our backend gives the AI app a special MCP token. Think of it as a hotel key card: it only opens the /mcp door, it can't be used to log in to the dashboard, and it expires and refreshes on its own.
4. Tools. From now on, on every message, the AI app asks our server for the list of tools this admin may use. The model picks one, fills in its inputs and sends the request with the token. Our backend checks it and runs it, and the AI tells the admin what it did.

In practice

Under the hood: the backend

The MCP layer is a new door into our existing NestJS backend, not a second backend. The dashboard and the AI end up calling the same service methods, with the same validation and the same permission checks. What differs is the entrance (/api/admin/... with a dashboard token, or /mcp with an MCP token) and who decides what to call: a person clicking buttons, or the model reading the tool list.

Two doors, one backend

The only extra step on the AI side is building a per-admin MCP server. From the permission check down, both paths run the same code.

The life of one tool call

1. POST /mcp — Everything goes through a single endpoint, built with the official MCP TypeScript SDK and its Streamable HTTP transport. A tool call is an ordinary HTTP POST with a JSON-RPC body.
2. McpAuthGuard — A dedicated Passport strategy verifies the token. Its audience must be our MCP URL, its scope must include mcp, and its mcpTokenVersion must match the user's current value in the database.
3. createMcpServer(userId) — We build a fresh MCP server for this admin and register only the tools their role allows. If they have no delete permission, the delete tools are never registered, so the AI doesn't know they exist.
4. Tool handler — The input is validated twice: against a Zod schema (which is also the input format the AI sees) and against the same class-validator DTO the admin controller uses. Then permissionService.assert() checks the specific permission, such as CREATE_ARTICLE.
5. The existing service — The handler calls the same method the dashboard uses, for example articleService.create(), which writes to PostgreSQL through Prisma.

Why a new server for every request

This was the most common question after the talk. There are three reasons:

• The tool list is personal. An MCP server holds one tool list. A shared server would show every admin the same tools, including ones they aren't allowed to use. Each tool handler also keeps the userId it was built with, so nothing can leak between users.
• The SDK requires it in stateless mode. We run the transport without sessions (sessionIdGenerator: undefined). In that mode the SDK expects a new server per request, because two clients can send the same JSON-RPC message ID at the same time and would collide on a shared server.
• Stateless is what we want anyway. Any backend instance can answer any request, so we can scale without sticky sessions. Permission changes apply on the very next request. Server and transport are closed when the response ends, so nothing builds up in memory.

Building the server is cheap: registering tools only creates objects in memory. The real cost is a few database lookups for permissions, which is fine at today's AI traffic levels.

200+ tools from one config per module

We didn't hand-write every tool. Each content module is described by one config object, and a generic registrar turns it into up to seven tools: list, get, create, update, publish, unpublish and delete.

{
  resource: 'article',
  permissions: { view, create, update, delete },
  service: articleService,
  createSchema, updateSchema,
  publishField: 'published',
}

Adding a new content module to MCP is mostly a matter of adding its config entry and schemas.

Security

The AI gets exactly the access the admin gives it, and the admin can take it back at any time. Four guarantees make that true:

How we protect the database

The AI never touches the database directly. It can only call the same functions our own UI calls, and every call passes through the same layers as a dashboard request:

1. Zod validation checks the shape and types of the arguments before anything runs.
2. The permission check confirms the admin's role allows this action.
3. Our NestJS services apply the same business rules as the dashboard.
4. Prisma talks to PostgreSQL using parameterized queries only.

The MCP layer contains no raw SQL at all, so there is no query string for SQL injection to target. It also contains no business logic of its own. When someone fixes a bug or adds a rule in a service, the dashboard and the AI both get the change automatically.

Lessons from building it

A few practical lessons that will help anyone building their own MCP server.

• Tool descriptions are prompts. The model chooses tools only from their names and descriptions, so we write them for the model. For example, a description can say "call list_options first to get valid category types". Then the AI looks up valid values itself instead of guessing.
• Keep responses small. Everything a tool returns goes into the AI's limited working memory (its context window). List tools return compact results, and every response is capped at about 12,000 characters.
• Return readable errors. When validation or a permission check fails, the AI gets a clear message instead of a crash. Most of the time it fixes its input and tries again on its own.
• Draft first, publish explicitly. Creating content as a draft keeps a person in the loop before anything goes live.
• Reuse the service layer. The biggest decision was not to write any database or business logic in the MCP layer. It kept the feature small, and it can't drift out of sync with the dashboard.

Possible next steps

• Load permissions once per request. Today each permission check reloads the user from the database. Caching the permission list for the length of a request would remove most of those lookups if AI traffic grows.
• Make AI Editor the default for connectors. Encouraging admins to connect AI with a dedicated, delete-free account would make the safe setup the easy one.

Takeaway

Learn more about Promo Core: sheenvalue.com/en/products/promo-core

Written by Eng. Hamza Kallajo