50:I[999133,["$9","$6","$a","$b","$c","$d","$e","$4","$5","$f","$10"],"BlogsListClient"] 51:T4f72,

أصبح بإمكان مسؤولي Promo Core الآن إدارة محتوى مواقعهم بمجرد التحدث إلى Claude أو ChatGPT أو Cursor. لم يعودوا بحاجة إلى التنقل بين صفحات الـ Dashboard، ولا يحصل الـ AI أبداً على صلاحيات أكثر من صلاحيات المسؤول الذي قام بربطه.

هذا المقال متابعة لعرضي التقديمي عن MCP. يشرح ما هو MCP، ولماذا أضفناه إلى Promo Core، وكيف يعمل من جهة المسؤول ومن جهة الـ Backend، وكيف نحافظ على أمانه. وفي النهاية أضفت بعض الدروس التي تعلمناها أثناء بنائه ولم يتسع لها وقت العرض.

ما هو MCP

MCP (Model Context Protocol) هو معيار مفتوح يتيح لتطبيقات الذكاء الاصطناعي (AI) استخدام أنظمة خارجية على شكل Tools. أطلقته Anthropic في نوفمبر 2024، وأصبح اليوم مدعوماً في Claude وChatGPT وCursor وVS Code.

الـ Model وحده لا يستطيع سوى كتابة النصوص. يمكنه أن يكتب لك مسودة مقال، لكن عليك نسخها إلى الـ Dashboard بنفسك. أما مع MCP فيستطيع الـ AI تنفيذ إجراءات حقيقية، مثل إنشاء ذلك المقال كمسودة مباشرة في الـ CMS.

قبل MCP كان لكل تطبيق AI نظام Plugins خاص به، لذلك كان لا بد من ربط كل Tool مع كل تطبيق على حدة. أما مع معيار موحد، فنكتب Server واحداً يعمل مع كل التطبيقات التي تدعم MCP. ولهذا يُشبَّه كثيراً بمنفذ USB-C للـ AI.

هناك ثلاثة أطراف:

الـ Model (عقل Claude أو ChatGPT): يقرأ طلب المستخدم ويقرر ما يجب فعله، لكنه لا يستطيع إرسال طلبات عبر الشبكة بنفسه.
تطبيق الـ AI (Claude.ai وChatGPT وCursor): هو الـ MCP Client، وهو من يرسل الطلبات الفعلية إلى الـ Server نيابةً عن الـ Model.
الـ MCP Server الخاص بنا: ينشر قائمة الـ Tools المتاحة وينفذها عند الطلب.

لكل Tool اسم (مثل create_article) ووصف بلغة بسيطة والمدخلات التي يحتاجها. الـ Model لا يرى الكود أبداً، بل يقرأ هذه الأوصاف فقط ويختار الـ Tool المناسب، لذلك فإن كتابة أوصاف جيدة جزء كبير من العمل.

يُستخدم MCP في مجالات أوسع بكثير من إدارة المحتوى: يربطه المطورون بالـ Repositories والـ CI، وتربطه الشركات بـ Jira وSlack وNotion، وتستخدمه فرق الدعم لجلب الـ Tickets وصياغة الردود. أما حالتنا فهي إدارة المحتوى.

لماذا أضفناه إلى Promo Core

أعطينا الـ CMS واجهة جديدة، لا Backend جديداً. وكانت هناك أربعة أسباب لذلك:

عمل أسرع على المحتوى. يصف المسؤول ما يريده بلغة طبيعية ("أضف سؤالاً شائعاً عن مدة التوصيل بالعربية والإنجليزية") بدلاً من تعبئة النماذج حقلاً حقلاً.
نفس البيانات. يمر الـ AI عبر نفس الـ NestJS Services التي يستخدمها الـ Dashboard، فلا يوجد نظام ثانٍ يحتاج إلى صيانة، ولا تختلف البيانات بين المكانين.
نفس الصلاحيات. يعمل الـ AI بهوية المسؤول الذي ربطه، وليس كمستخدم بصلاحيات كاملة، ولا يستطيع فعل إلا ما يستطيع هذا المسؤول فعله في الـ Dashboard.
كل عميل يحصل عليه. Promo Core هو White-label Starter ننسخه لكل عميل، لذلك يحصل كل مشروع جديد على CMS جاهز للعمل مع الـ AI منذ البداية.

كيف يعمل من جهة المسؤول

يستغرق الربط حوالي دقيقة ويتم مرة واحدة فقط. بعدها يكفي أن يتحدث المسؤول مع الـ AI.

الربط (Connect). يضيف المسؤول Connector جديداً في Claude أو ChatGPT ويلصق رابط الـ MCP الخاص بنا. تعرض صفحة Connectors في الـ Dashboard هذا الرابط، مع دليل خطوة بخطوة لكل من Claude وChatGPT وCursor. وعندما يحاول Claude الاتصال لأول مرة، يرد الـ Backend بأنه غير مصرح له ويخبره أين يسجل الدخول.
الموافقة (Consent). يفتح Claude صفحة الموافقة في الـ Dashboard. يسجل المسؤول الدخول بحسابه المعتاد في Promo Core، ويرى أي تطبيق يطلب الوصول، ثم يضغط Approve. إنها نفس طريقة "Sign in with…" المألوفة (والمعيار الذي تعتمد عليه اسمه OAuth)، لذلك لا يعطي المسؤول كلمة المرور لـ Claude أو ChatGPT أبداً.
الـ Token. يمنح الـ Backend تطبيق الـ AI ما يسمى MCP Token. يمكن تشبيهه ببطاقة غرفة الفندق: لا يفتح إلا باب /mcp، ولا يمكن استخدامه لتسجيل الدخول إلى الـ Dashboard، وتنتهي صلاحيته ويتجدد تلقائياً.
الـ Tools. من الآن فصاعداً، ومع كل رسالة، يطلب تطبيق الـ AI من الـ Server قائمة الـ Tools المسموح بها لهذا المسؤول. يختار الـ Model واحداً منها ويعبئ مدخلاته ويرسل الطلب مع الـ Token. يتحقق الـ Backend من الطلب وينفذه، ثم يخبر الـ AI المسؤول بما قام به.

إليك كيف يبدو ذلك عملياً:

ما يكتبه المسؤول	الـ Tool الذي يستدعيه الـ AI
"اعرض المقالات المحفوظة كمسودات"	`list_articles`
"أنشئ سؤالاً شائعاً عن الأسعار"	`create_faq`
"ارفع هذه الصورة إلى الـ Media"	`upload_media`
"اعرض الإجابات المرسلة على النموذج رقم 7"	`list_form_submissions`
"انشر المشروع رقم 12"	`publish_project`
"عدّل عنوان صفحة About"	`update_page`

لا يحتاج المسؤول إلى معرفة أسماء هذه الـ Tools. يُنشأ المحتوى الجديد كمسودة (Draft) بشكل افتراضي، لذلك يراجعه شخص قبل نشره، ويبقى النشر دائماً خطوة منفصلة وصريحة.

ما يحدث في الـ Backend

طبقة MCP هي باب جديد إلى الـ NestJS Backend الحالي، وليست Backend ثانياً. ينتهي كل من الـ Dashboard والـ AI إلى استدعاء نفس الـ Service Methods، بنفس الـ Validation ونفس فحوصات الصلاحيات. الفرق فقط في المدخل (/api/admin/... مع Dashboard Token، أو /mcp مع MCP Token)، وفي من يقرر ما الذي يُستدعى: شخص يضغط الأزرار، أو Model يقرأ قائمة الـ Tools.

مساران وBackend واحد

مسار الـ Dashboard: المسؤول يضغط Save ← /api/admin/... مع Dashboard Token ← الـ Validation وفحص الصلاحيات.
مسار الـ AI: Claude أو ChatGPT أو Cursor ← POST /mcp مع MCP Token يتحقق منه McpAuthGuard ← createMcpServer(userId) مع الـ Tools التي يسمح بها دور المستخدم فقط ← الـ Validation وفحص الصلاحيات.
الجزء المشترك: الـ NestJS Services الحالية (مثل articleService.create()) ← Prisma ← PostgreSQL.

الخطوة الإضافية الوحيدة في مسار الـ AI هي إنشاء MCP Server خاص بكل مسؤول. ومن فحص الصلاحيات فما دون، ينفذ المساران نفس الكود.

يمر استدعاء الـ Tool الواحد بخمس خطوات:

POST /mcp. كل شيء يمر عبر Endpoint واحد، مبني باستخدام الـ MCP TypeScript SDK الرسمي مع Streamable HTTP Transport. واستدعاء الـ Tool هو مجرد HTTP POST عادي يحمل JSON-RPC Body.
McpAuthGuard. تتحقق Passport Strategy مخصصة من الـ Token: يجب أن يكون الـ Audience هو رابط الـ MCP الخاص بنا، وأن يتضمن الـ Scope القيمة mcp، وأن يطابق mcpTokenVersion القيمة الحالية للمستخدم في قاعدة البيانات.
createMcpServer(userId). ننشئ MCP Server جديداً لهذا المسؤول، ونسجل فيه فقط الـ Tools التي يسمح بها دوره. وإذا لم تكن لديه صلاحية الحذف، فلا تُسجَّل Tools الحذف أصلاً، ولا يعرف الـ AI بوجودها.
الـ Tool Handler. يتم التحقق من المدخلات مرتين: مرة عبر Zod Schema (وهو نفسه شكل المدخلات الذي يراه الـ AI)، ومرة عبر نفس الـ class-validator DTO الذي يستخدمه الـ Admin Controller. بعد ذلك يتحقق permissionService.assert() من الصلاحية المطلوبة، مثل CREATE_ARTICLE.
الـ Service الحالي. يستدعي الـ Handler نفس الـ Method التي يستخدمها الـ Dashboard، مثل articleService.create()، والتي تكتب في PostgreSQL عبر Prisma.

لماذا ننشئ Server جديداً لكل Request

كان هذا أكثر سؤال طُرح بعد العرض، وهناك ثلاثة أسباب:

قائمة الـ Tools شخصية. يحمل الـ MCP Server قائمة Tools واحدة. ولو استخدمنا Server مشتركاً لرأى كل المسؤولين نفس الـ Tools، بما فيها ما لا يُسمح لهم باستخدامه. كما يحتفظ كل Tool Handler بالـ userId الذي أُنشئ به، فلا يمكن أن يتسرب أي شيء بين المستخدمين.
الـ SDK يتطلب ذلك في الـ Stateless Mode. نشغّل الـ Transport بدون Sessions (sessionIdGenerator: undefined). وفي هذا الوضع يتوقع الـ SDK إنشاء Server جديد لكل Request، لأن عميلين قد يرسلان نفس الـ JSON-RPC Message ID في الوقت نفسه، فتتعارض الرسائل على Server مشترك.
الـ Stateless هو ما نريده أصلاً. يمكن لأي Instance من الـ Backend الرد على أي Request، فنستطيع التوسع دون الحاجة إلى Sticky Sessions. وتُطبَّق تغييرات الصلاحيات من الـ Request التالي مباشرة. كما يُغلق الـ Server والـ Transport عند انتهاء الـ Response، فلا يتراكم شيء في الذاكرة.

إنشاء الـ Server عملية خفيفة، لأن تسجيل الـ Tools ينشئ Objects في الذاكرة فقط. أما التكلفة الحقيقية فهي بعض الاستعلامات من قاعدة البيانات لفحص الصلاحيات، وهذا مقبول تماماً بحجم استخدام الـ AI الحالي.

أكثر من 200 Tool من Config واحد لكل Module

لم نكتب كل Tool يدوياً. كل Content Module موصوف بـ Config Object واحد، ويحوّله Registrar عام إلى ما يصل إلى سبعة Tools: list وget وcreate وupdate وpublish وunpublish وdelete.

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

هناك 26 Module مُعرّفة بهذه الطريقة، ما ينتج ما يصل إلى 174 Tool. وهناك حوالي 90 Tool أخرى مكتوبة يدوياً للعمليات التي ليست مجرد CRUD: رفع الـ Media، وإصدارات الـ Forms، والـ Email Templates، والـ Push Notifications، والأدوار والمسؤولين، والإعدادات، والـ Import/Export Jobs. وإضافة Content Module جديد إلى MCP تقتصر في الغالب على إضافة الـ Config والـ Schemas الخاصة به.

الأمان

يحصل الـ AI على الصلاحيات التي يمنحها له المسؤول بالضبط، ويستطيع المسؤول سحبها في أي وقت. وهناك أربع ضمانات تحقق ذلك:

الضمان	ماذا يعني	كيف يُطبَّق
الموافقة مطلوبة	لا يمكن لأي AI الاتصال قبل أن يسجل المسؤول الدخول ويوافق	OAuth 2.1 مع PKCE (S256 فقط)، وقائمة مسموحة من الـ Redirect URLs
MCP Token منفصل	لا يصل Dashboard Token إلى `/mcp`، ولا يستطيع MCP Token استدعاء الـ Dashboard API	تحمل الـ MCP Tokens قيمة Audience خاصة بها، وScope باسم `mcp`، وعداد إصدار خاصاً بها
صلاحيات الدور تُطبَّق	إذا كان دورك لا يسمح بإنشاء مقالات في الـ Dashboard، فلن يستطيع الـ AI ذلك أيضاً	كل Tool يفحص صلاحيته قبل التنفيذ، والـ Tools غير المسموح بها لا تُسجَّل أصلاً
سهولة إلغاء الوصول	ضغطة واحدة تفصل كل تطبيقات الـ AI دون تسجيل خروج المسؤول من الـ Dashboard	الإلغاء يزيد قيمة `mcpTokenVersion`، فتصبح كل الـ MCP Tokens السابقة لهذا المسؤول غير صالحة

كما نضيف عبر الـ Seeder دوراً باسم AI Editor يملك صلاحيات العرض والإنشاء والتعديل على المحتوى، دون أي صلاحية حذف. ربط الـ AI بهذا الدور يعني أنه يستطيع كتابة المسودات وتعديلها، لكنه لا يستطيع حذف أي شيء. والـ Tools التي تحذف مُعلَّمة على أنها Destructive، حتى تتمكن تطبيقات الـ AI من طلب تأكيد المستخدم قبل استدعائها. كما تُسجَّل استدعاءات الـ Tools في الـ Logs مع اسم الـ Tool والـ User ID.

كيف نحمي قاعدة البيانات

لا يتعامل الـ AI مع قاعدة البيانات مباشرة أبداً. كل ما يستطيعه هو استدعاء نفس الدوال التي تستدعيها واجهتنا، ويمر كل استدعاء عبر نفس الطبقات التي يمر بها Request الـ Dashboard:

Zod Validation يتحقق من شكل المدخلات وأنواعها قبل تنفيذ أي شيء.
فحص الصلاحيات يتأكد من أن دور المسؤول يسمح بهذا الإجراء.
الـ NestJS Services تطبق نفس الـ Business Rules المطبقة في الـ Dashboard.
Prisma يتعامل مع PostgreSQL باستخدام Parameterized Queries فقط.

لا تحتوي طبقة MCP على أي Raw SQL إطلاقاً، فلا يوجد Query String يمكن استهدافه بـ SQL Injection. كما أنها لا تحتوي على أي Business Logic خاص بها. وعندما يصلح أحدهم Bug أو يضيف قاعدة جديدة في أحد الـ Services، يحصل كل من الـ Dashboard والـ AI على التغيير تلقائياً.

دروس من بناء المشروع

لم يتسع لها وقت العرض، لكنها ستفيد كل من يبني MCP Server.

أوصاف الـ Tools هي Prompts. يختار الـ Model الـ Tools بناءً على أسمائها وأوصافها فقط، لذلك نكتبها موجهة للـ Model. مثلاً، يمكن أن يقول الوصف: "call list_options first to get valid category types"، وعندها يبحث الـ AI عن القيم الصحيحة بنفسه بدلاً من التخمين.
اجعل الـ Responses صغيرة. كل ما يعيده الـ Tool يدخل في الذاكرة العاملة المحدودة للـ AI (الـ Context Window). لذلك تعيد Tools القوائم نتائج مختصرة، وكل Response محدود بحوالي 12,000 حرف.
أعِد رسائل خطأ مفهومة. عندما يفشل الـ Validation أو فحص الصلاحيات، يتلقى الـ AI رسالة واضحة بدلاً من Crash، وفي أغلب الأحيان يصحح مدخلاته ويعيد المحاولة بنفسه.
المسودة أولاً، ثم النشر بشكل صريح. إنشاء المحتوى كمسودة يُبقي شخصاً في الحلقة قبل نشر أي شيء.
أعِد استخدام طبقة الـ Services. أهم قرار اتخذناه هو عدم كتابة أي Database Logic أو Business Logic داخل طبقة MCP. هذا أبقى الميزة صغيرة، ويمنعها من الاختلاف عن الـ Dashboard مع الوقت.

خطوات مقترحة للمستقبل

تحميل الصلاحيات مرة واحدة لكل Request. حالياً، كل فحص صلاحية يعيد تحميل المستخدم من قاعدة البيانات. وتخزين قائمة الصلاحيات مؤقتاً (Caching) طوال مدة الـ Request سيلغي معظم هذه الاستعلامات إذا زاد استخدام الـ AI.
جعل AI Editor الدور الافتراضي للـ Connectors. تشجيع المسؤولين على ربط الـ AI بحساب مخصص بدون صلاحيات حذف يجعل الإعداد الآمن هو الإعداد الأسهل.

الخلاصة

MCP جسر آمن بين الـ AI والـ CMS الخاص بنا. يعمل الـ AI بهوية المسؤول الذي ربطه، وبموافقته وصلاحياته، ويمكن سحب الوصول في أي وقت. وهو ليس CMS ثانياً، بل يستخدم نفس الـ Services ويتبع نفس القواعد.

لتجربته، افتح صفحة Connectors في Promo Core Dashboard واتبع الدليل الخاص بـ Claude أو ChatGPT أو Cursor. ويسعدني تلقي أسئلتكم وأفكاركم في أي وقت.

52:T3780,

Promo Core admins can now manage their website content by talking to Claude, ChatGPT or Cursor. They don't need to click through the dashboard, and the AI never gets more access than the admin who connected it.

This article follows up on my MCP presentation. It covers what MCP is, why we built it into Promo Core, how it works from the admin's side and the backend side, and how we keep it safe. At the end I've added a few lessons from building it that didn't fit in the talk.

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. Claude, ChatGPT, Cursor and VS Code now support it.

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.

Before MCP, every AI app had its own plugin system, so each tool had to be integrated separately with each app. With a shared standard, we write one server and it works in every app that supports MCP. People often call it "USB-C for AI".

There are three players:

The model (Claude's or ChatGPT's "brain") reads the user's request and decides what to do. It can't make network calls itself.
The AI app (Claude.ai, ChatGPT, Cursor) is the MCP client. It makes the actual calls to our server for the model.
Our MCP server publishes a list of tools and runs them when asked.

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.

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.
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.
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.
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.

Here is what that looks like in practice:

The admin types	The AI calls
"List draft articles"	`list_articles`
"Create a FAQ about pricing"	`create_faq`
"Upload this image to media"	`upload_media`
"Show submissions for form 7"	`list_form_submissions`
"Publish project #12"	`publish_project`
"Update the About page title"	`update_page`

The admin never needs to know these tool names. New content is created as a draft by default, so a person still reviews it before it goes live. Publishing is always a separate, explicit step.

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

Dashboard path: the admin clicks Save → /api/admin/... with a dashboard token → validation and permission check.
AI path: Claude, ChatGPT or Cursor → POST /mcp with an MCP token, checked by McpAuthGuard → createMcpServer(userId) with only the tools this role allows → validation and permission check.
Shared part: the existing NestJS services (such as articleService.create()) → Prisma → PostgreSQL.

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.

One tool call goes through five steps:

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.
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.
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.
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.
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',
}

26 modules are configured this way, which gives up to 174 generated tools. Around 90 more are hand-written for work that isn't plain create/read/update/delete: media upload, form versions, email templates, push notifications, roles and admins, settings, and import/export jobs. 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:

Guarantee	What it means	How it's enforced
Consent required	No AI can connect until an admin logs in and approves it	OAuth 2.1 with PKCE (S256 only), plus an allowlist of redirect URLs
Separate MCP token	A dashboard token can't reach `/mcp`, and an MCP token can't call the dashboard API	MCP tokens carry their own audience, an `mcp` scope and their own version counter
Role permissions apply	If your role can't create articles in the dashboard, the AI can't either	Every tool checks its permission before running; tools you can't use aren't registered
Easy to revoke	One click disconnects every AI client without logging the admin out of the dashboard	Revoking increments `mcpTokenVersion`, which invalidates all existing MCP tokens for that admin

We also seed an AI Editor role with view, create and update permissions on content but no delete permissions. Giving an AI connection this role means it can draft and edit but cannot destroy anything. Tools that do delete are marked as destructive, so AI apps can ask the user to confirm before calling them. Tool calls are logged with the tool name and the user ID.

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:

Zod validation checks the shape and types of the arguments before anything runs.
The permission check confirms the admin's role allows this action.
Our NestJS services apply the same business rules as the dashboard.
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

These didn't fit in the presentation, but they'll help anyone who builds an 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

MCP is a safe bridge between AI and our CMS. The AI works as the admin who connected it, with that admin's consent and permissions, and access can be revoked at any time. It isn't a second CMS: it uses the same services and follows the same rules.

To try it, open the Connectors page in the Promo Core dashboard and follow the guide for Claude, ChatGPT or Cursor. Questions and ideas are welcome, so reach out to me any time.

53:T3780,

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. Claude, ChatGPT, Cursor and VS Code now support it.

There are three players:

The model (Claude's or ChatGPT's "brain") reads the user's request and decides what to do. It can't make network calls itself.
The AI app (Claude.ai, ChatGPT, Cursor) is the MCP client. It makes the actual calls to our server for the model.
Our MCP server publishes a list of tools and runs them when asked.

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.

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.
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.
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.
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.

Here is what that looks like in practice:

The admin types	The AI calls
"List draft articles"	`list_articles`
"Create a FAQ about pricing"	`create_faq`
"Upload this image to media"	`upload_media`
"Show submissions for form 7"	`list_form_submissions`
"Publish project #12"	`publish_project`
"Update the About page title"	`update_page`

The admin never needs to know these tool names. New content is created as a draft by default, so a person still reviews it before it goes live. Publishing is always a separate, explicit step.

Under the hood: the backend

Two doors, one backend

Dashboard path: the admin clicks Save → /api/admin/... with a dashboard token → validation and permission check.
AI path: Claude, ChatGPT or Cursor → POST /mcp with an MCP token, checked by McpAuthGuard → createMcpServer(userId) with only the tools this role allows → validation and permission check.
Shared part: the existing NestJS services (such as articleService.create()) → Prisma → PostgreSQL.

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.

One tool call goes through five steps:

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.
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.
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.
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.
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

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

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:

Guarantee	What it means	How it's enforced
Consent required	No AI can connect until an admin logs in and approves it	OAuth 2.1 with PKCE (S256 only), plus an allowlist of redirect URLs
Separate MCP token	A dashboard token can't reach `/mcp`, and an MCP token can't call the dashboard API	MCP tokens carry their own audience, an `mcp` scope and their own version counter
Role permissions apply	If your role can't create articles in the dashboard, the AI can't either	Every tool checks its permission before running; tools you can't use aren't registered
Easy to revoke	One click disconnects every AI client without logging the admin out of the dashboard	Revoking increments `mcpTokenVersion`, which invalidates all existing MCP tokens for that admin

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:

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

Lessons from building it

These didn't fit in the presentation, but they'll help anyone who builds an 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

To try it, open the Connectors page in the Promo Core dashboard and follow the guide for Claude, ChatGPT or Cursor. Questions and ideas are welcome, so reach out to me any time.

26:["$","$L50",null,{"articles":[{"id":9,"sortOrder":0,"published":true,"featured":true,"translations":[{"locale":"ar","title":"كيف منحنا الـ AI وصولاً آمناً إلى Promo Core باستخدام MCP","slug":"how-we-gave-ai-safe-access-to-promo-core-with-mcp-ar","description":"كيف يمكن لمسؤولي Promo Core إدارة محتوى الموقع عبر Claude أو ChatGPT أو Cursor باستخدام MCP، وكيف نحافظ على أمان ذلك.","body":"$51","date":"2026-10-27","metaDescription":"يدعم Promo Core الآن MCP: يدير المسؤولون محتوى الـ CMS بالتحدث إلى Claude أو ChatGPT أو Cursor، مع الموافقة المسبقة وصلاحيات الأدوار وإمكانية إلغاء الوصول بضغطة واحدة.","metaKeyword":"MCP, Model Context Protocol, AI, CMS, NestJS, OAuth, Promo Core","coverMediaId":"6d28a914-5c0b-4ebf-bfb4-1009f1469ffa","coverMedia":{"id":"6d28a914-5c0b-4ebf-bfb4-1009f1469ffa","path":"/uploads/article/2026-10/6d28a914-5c0b-4ebf-bfb4-1009f1469ffa.svg","type":"IMAGE"}},{"locale":"en","title":"How We Gave AI Safe Access to Promo Core with MCP","slug":"how-we-gave-ai-safe-access-to-promo-core-with-mcp","description":"How Promo Core admins can manage website content through Claude, ChatGPT or Cursor using MCP, and how we keep it safe.","body":"$52","date":"2026-10-27","metaDescription":"Promo Core now supports MCP: admins manage CMS content by talking to Claude, ChatGPT or Cursor, with consent, role permissions and one-click revoke.","metaKeyword":"MCP, Model Context Protocol, AI, CMS, NestJS, OAuth, Promo Core","coverMediaId":"07f434ab-8837-4130-ba23-ded22edba04e","coverMedia":{"id":"07f434ab-8837-4130-ba23-ded22edba04e","path":"/uploads/article/2026-10/07f434ab-8837-4130-ba23-ded22edba04e.png","type":"IMAGE"}}],"articleCategories":[{"id":27,"type":"ARTICLE","sortOrder":20,"featured":false,"published":true,"createdAt":"2026-10-28T06:53:05.378Z","updatedAt":"2026-10-28T06:53:05.378Z","translations":[{"id":53,"title":"الذكاء الاصطناعي","slug":"category-7","description":"مقالات عن الذكاء الاصطناعي وأدواته وكيف نستخدمه في منتجاتنا.","metaDescription":"مقالات عن الذكاء الاصطناعي وأدواته وكيف نستخدمه في منتجاتنا.","metaKeyword":"AI, الذكاء الاصطناعي, MCP, LLM","locale":"ar","translatableId":27,"createdAt":"2026-10-28T06:53:05.378Z","updatedAt":"2026-10-28T06:53:05.378Z"},{"id":54,"title":"AI","slug":"ai","description":"Articles about artificial intelligence, AI tools and how we use them in our products.","metaDescription":"Articles about artificial intelligence, AI tools and how we use them in our products.","metaKeyword":"AI, Artificial Intelligence, MCP, LLM","locale":"en","translatableId":27,"createdAt":"2026-10-28T06:53:05.378Z","updatedAt":"2026-10-28T06:53:05.378Z"}],"images":[],"title":"AI","slug":"ai","description":"Articles about artificial intelligence, AI tools and how we use them in our products.","metaDescription":"Articles about artificial intelligence, AI tools and how we use them in our products.","metaKeyword":"AI, Artificial Intelligence, MCP, LLM","translatableId":27}],"images":[{"id":7,"sortOrder":0,"translations":[{"id":13,"locale":"en","mediaId":"7ad7e1a8-4361-4b33-b147-e30ed0f26963","media":{"id":"7ad7e1a8-4361-4b33-b147-e30ed0f26963","path":"/uploads/article/2026-10/7ad7e1a8-4361-4b33-b147-e30ed0f26963.png","type":"IMAGE"}}]}],"title":"How We Gave AI Safe Access to Promo Core with MCP","slug":"how-we-gave-ai-safe-access-to-promo-core-with-mcp","description":"How Promo Core admins can manage website content through Claude, ChatGPT or Cursor using MCP, and how we keep it safe.","body":"$53","date":"2026-10-27","metaDescription":"Promo Core now supports MCP: admins manage CMS content by talking to Claude, ChatGPT or Cursor, with consent, role permissions and one-click revoke.","metaKeyword":"MCP, Model Context Protocol, AI, CMS, NestJS, OAuth, Promo Core","coverMediaId":"07f434ab-8837-4130-ba23-ded22edba04e","coverMedia":{"id":"07f434ab-8837-4130-ba23-ded22edba04e","path":"/uploads/article/2026-10/07f434ab-8837-4130-ba23-ded22edba04e.png","type":"IMAGE"},"createdAt":"2026-10-28T06:50:08.357Z","updatedAt":"2026-10-28T07:22:02.557Z"}],"hasCategoryFilter":false}] 3d:null

THINK. BUILD. GROW

How We Gave AI Safe Access to Promo Core with MCP

Quick links

THINK. BUILD. GROW

How We Gave AI Safe Access to Promo Core with MCP

Bringing your ideas to life!

Contact