ساخت MCP server برای مارکتینگ: راهنمای گام‌به‌گام

آخرین به‌روزرسانی: ژوئیه 2026

اگر تیم مارکتینگ شما بین GA4، سرچ کنسول، CRM و ابزار تولید محتوا مدام رفت‌وآمد می‌کند، MCP server یک لایه عملی برای جمع‌کردن این اتصال‌هاست. ایده ساده است. به‌جای ساختن ده‌ها اتصال پراکنده، یک سرور می‌سازی که داده، مجوز و اکشن‌ها را استاندارد به ایجنت یا مدل هوش مصنوعی می‌دهد. نتیجه، اتوماسیون قابل‌کنترل‌تر و خطای کمتر است.

خلاصه سریع

• MCP server، اتصال استاندارد بین ابزارها و ایجنت‌ها می‌سازد.
• برای مارکتینگ، داده و اکشن‌ها را در یک لایه امن جمع می‌کند.
• با یک طراحی درست، توسعه و نگهداری بسیار ساده‌تر می‌شود.
• این راهنما از نیازسنجی تا تست و استقرار را مرحله‌به‌مرحله می‌گوید.

MCP server چیست و چرا برای مارکتینگ مهم است؟

MCP server یک واسط استاندارد بین مدل هوش مصنوعی و ابزارهای واقعی شماست. به‌جای اینکه هر ایجنت مستقیم به APIهای مختلف وصل شود، سرور ابزارها را با ورودی، خروجی و مجوز مشخص ارائه می‌کند. اگر تعریف پایه را دقیق‌تر می‌خواهی، توضیح کامل MCP server به فارسی چارچوب ذهنی خوبی می‌دهد.

برای مارکتینگ، ارزش اصلی در تمرکز است. گزارش GA4، کوئری‌های GSC، وضعیت کمپین ایمیل و حتی ساخت بریف محتوا می‌توانند از یک نقطه کنترل شوند. این مدل برای تیم‌هایی که به ایجنت‌های بازاریابی و اتوماسیون عملی فکر می‌کنند، خیلی منطقی‌تر از اسکریپت‌های پراکنده است.

مثال واقعی، یک ایجنت محتواست که هر صبح ۲۰ کوئری افت‌کرده را از GSC می‌گیرد، صفحات مرتبط را پیدا می‌کند و بریف بازنویسی می‌سازد. اگر این جریان روی یک MCP server باشد، هم لاگ دارید، هم محدودیت دسترسی، هم توسعه‌اش ساده‌تر می‌شود.

قبل از ساخت: نیازهای دقیق تیم مارکتینگ را مشخص کنید

اول از ابزار شروع نکن. از کارهای تکراری شروع کن. مثلا تیم سئو شاید سه نیاز ثابت داشته باشد، گرفتن کوئری‌های رتبه ۸ تا ۱۲، استخراج صفحات با افت کلیک، و ساخت پیش‌نویس بریف. تیم پرفورمنس احتمالاً گزارش هزینه، تبدیل و جابه‌جایی بودجه می‌خواهد.

بعد، داده‌ها و اکشن‌ها را جدا کن. داده یعنی read، مثل گرفتن session از ابزارهای MCP برای GA4. اکشن یعنی write، مثل ساخت draft در Notion یا توقف یک کمپین. این تفکیک مهم است، چون مجوز read-only باید پیش‌فرض باشد.

فهرست نهایی را در سه ستون بنویس. منبع داده، ابزار MCP، و نتیجه مورد انتظار. یک نمونه ساده، GSC، تابع get_low_ctr_queries، خروجی CSV با ۵۰ ردیف. اگر برای سئو کار می‌کنی، تحلیل سرچ کنسول با Claude Code بهت ایده خوبی برای تعریف این ابزارها می‌دهد.

معماری پیشنهادی برای ساخت MCP server

یک معماری ساده کافی است. لایه اول، transport و protocol. لایه دوم، registry ابزارها. لایه سوم، connectorها برای APIهای بیرونی. لایه چهارم، auth، rate limit و logging. این ساختار باعث می‌شود وقتی سرچ کنسول یا GA4 عوض شد، کل سرور را دست نزنی.

بهتر است هر connector فقط یک کار روشن داشته باشد. مثلا gsc-keywords فقط داده خام کوئری را برگرداند. تفسیر، خوشه‌بندی یا ساخت بریف در لایه ابزارهای بالاتر انجام شود. اگر آماده شروع هستی، سرورهای MCP آماده برای Claude نمونه خوبی از این تفکیک هستند.

مراحل ساخت: از اسکلت اولیه تا ابزارهای قابل‌استفاده

پروژه را با یک اسکلت کوچک شروع کن. اول server بالا بیاید، health check بدهد و یک ابزار تستی مثل ping داشته باشد. بعد، ابزارهای واقعی را یکی‌یکی اضافه کن. زود سراغ ۱۵ ابزار نرو. سه ابزار پایدار بهتر از ده ابزار نصفه است.

ترتیب عملی کار معمولاً این است:

1. تعریف schema ورودی و خروجی هر ابزار.
2. ساخت connector برای API منبع.
3. افزودن validation و پیام خطای قابل‌فهم.
4. تست محلی با داده ساختگی.
5. اتصال به credential واقعی در محیط staging.

یک نمونه ابزار می‌تواند این باشد:

{
  "name": "get_low_ctr_queries",
  "input": { "page": "string", "days": 28, "limit": 50 },
  "output": { "queries": "array", "avg_position": "number" },
  "errors": ["unauthorized", "quota_exceeded", "invalid_page"]
}

برای تیم محتوا، ابزار دوم می‌تواند draft_content_brief باشد که خروجی get_low_ctr_queries را مصرف کند. اینجا اتصال به ورک‌فلو تولید بریف محتوا با AI خیلی کاربردی می‌شود، چون از داده خام به اقدام واقعی می‌رسی.

تست، امنیت و کنترل دسترسی را چگونه تنظیم کنیم؟

سه چیز را از روز اول اجباری کن. احراز هویت، لاگ، و محدودسازی دسترسی. هر ابزار باید scope مشخص داشته باشد. مثلا analyst فقط read ببیند، اما lead بتواند export بسازد. tokenهای سرویس را هم داخل vault یا secret manager نگه دار، نه در کد.

تست فقط unit test نیست. باید failure واقعی را هم شبیه‌سازی کنی. مثلا quota گوگل تمام شود، page نامعتبر باشد، یا پاسخ API دیر برسد. بسیاری از تیم‌ها این بخش را نادیده می‌گیرند و بعد در محیط واقعی غافلگیر می‌شوند. برای اتصال سرچ کنسول، نمونه MCP گوگل سرچ کنسول معیار خوبی برای scopeبندی و ابزارهای read-only است.

استقرار و نگهداری: از نسخه اول تا بهبودهای بعدی

نسخه اول را کوچک نگه دار. یک deployment روی staging، سه ابزار اصلی، و مانیتورینگ ساده کافی است. شاخص‌هایی مثل latency، error rate و تعداد فراخوانی هر ابزار را ثبت کن. اگر ابزاری کم‌استفاده است، شاید اصلا نباید در MVP باشد.

بعد از انتشار، از تیم مارکتینگ بازخورد رفتاری بگیر، نه فقط نظر کلی. ببین کدام promptها تکرار می‌شوند، کدام خروجی‌ها نیاز به post-processing دارند، و کجا write access واقعاً لازم است. اگر هزینه و دامنه اجرا برایت مهم است، بررسی هزینه پیاده‌سازی و نگهداری سئو کمک می‌کند واقع‌بینانه برنامه‌ریزی کنی.

سوالات متداول

آیا برای ساخت MCP server باید برنامه‌نویس حرفه‌ای باشم؟

نه لزوماً، اما باید منطق API، احراز هویت و ساختار داده را خوب بفهمی. اگر بتوانی یک endpoint ساده بسازی و JSON را درست مدیریت کنی، MVP قابل‌ساخت است. بخش سخت‌تر، طراحی scopeها و خطاهاست، نه نوشتن کد خام. برای تیم‌های کوچک، همکاری یک مارکتر فنی با یک توسعه‌دهنده معمولاً کافی است.

MCP server با API معمولی چه تفاوتی دارد؟

API معمولی فقط دسترسی به یک سرویس می‌دهد. MCP server همان دسترسی را برای مصرف ایجنت‌ها استاندارد می‌کند. یعنی ابزار، schema، مجوز و رفتار خطاها را در یک لایه مشترک می‌آورد. این تفاوت کوچک نیست. چون وقتی چند منبع داده و چند workflow داری، یک API تنها نظم عملیاتی لازم را به‌تنهایی نمی‌دهد.

برای مارکتینگ کدام ابزارها را اول وصل کنیم؟

اول از منابع read-heavy شروع کن. معمولاً GSC، GA4 و یک منبع محتوایی مثل Notion یا CMS بهترین شروع هستند. دلیلش ساده است. داده می‌گیری، تحلیل می‌سازی، ولی هنوز ریسک write نداری. ابزارهایی مثل pause campaign یا edit page را بگذار برای فاز دوم، وقتی لاگ و کنترل دسترسی‌ات کاملاً پایدار شد.

چطور امنیت داده‌های مشتری را در MCP server حفظ کنیم؟

حداقل‌گرایی بهترین اصل است. فقط داده لازم را بگیر، فقط scope لازم را بده، و خروجی حساس را log نکن. tokenها باید در secret manager بمانند. دسترسی‌ها هم role-based باشند. اگر چند مشتری داری، tenant isolation جدی است. یعنی داده هر مشتری، credential هر مشتری و لاگ هر مشتری باید از هم جدا بماند.

آیا می‌توان MCP server را برای چند تیم استفاده کرد؟

بله، اگر از ابتدا multi-tenant یا حداقل multi-role طراحی شده باشد. تیم سئو، محتوا و پرفورمنس می‌توانند روی یک server باشند، اما registry ابزارها و scopeها باید جدا شوند. مشکل وقتی شروع می‌شود که همه ابزارها برای همه باز باشند. تفکیک namespace، quota و audit log این ریسک را خیلی کمتر می‌کند.

ساخت MVP از MCP server چقدر زمان می‌برد؟

برای یک MVP جمع‌وجور با ۳ ابزار read-only، در بسیاری از موارد ۳ تا ۷ روز کاری کافی است. اگر auth سازمانی، logging کامل و staging درست بخواهی، بازه می‌تواند به ۲ هفته برسد. چیزی که زمان را می‌خورد، معمولاً کدنویسی نیست. هماهنگی credentialها، تست خطاها و شفاف‌کردن نیاز واقعی تیم است.

اگر قرار است همین هفته شروع کنی، فقط یک use case را انتخاب کن. مثلا استخراج کوئری‌های افت‌کرده و ساخت بریف بازنویسی. همان را کامل، امن و قابل‌تست بساز. بیشتر پروژه‌های MCP نه از کمبود ایده، بلکه از زیادبودن دامنه در نسخه اول ضربه می‌خورند.