قسمت ۱۰ از ۱۱ MCP — ساخت ابزارهای متصل به AI

اگه از اول می‌خوای، اینجا رو بزن

پروژه نهایی — ساخت دستیار هوشمند کسب‌وکار

قسمت ۱۰ ۲۰ دقیقه

قبلاً چی گفتیم؟

تبریک! رسیدی به آخرین قسمت سری MCP — ساخت ابزارهای متصل به AI. تا اینجا یه مسیر طولانی طی کردیم: از مفهوم MCP و چرایی وجودش شروع کردیم، اولین سرور رو نصب و راه‌اندازی کردیم، با ساخت سرور اختصاصی آشنا شدیم، Resources و Prompts رو کشف کردیم، به Claude و مدل‌های دیگه وصلش کردیم، امنیت رو جدی گرفتیم و سیستم رو به پروداکشن بردیم.

حالا وقتشه همه این تکه‌ها رو کنار هم بذاریم و یه پروژه واقعی طراحی کنیم: یه دستیار هوشمند کسب‌وکار که از چند MCP Server به‌صورت هماهنگ استفاده می‌کنه.

درباره این قسمت
این قسمت بیشتر طراحی و معماری هست تا کدنویسی سنگین. هدف اینه که ببینی چطور قطعات مختلف MCP رو مثل لِگو کنار هم می‌چینی تا یه سیستم واقعی بسازی. کدها مفهومی و کوتاهن — تمرکز روی «چرا» و «چطور فکر کردن» هست.

چی می‌خوایم بسازیم؟

فرض کن یه شرکت داری (یا توش کار می‌کنی) و هر روز با یه عالمه سوال و درخواست مواجهی:

  • «فروش ماه گذشته چقدر بود؟»
  • «درباره محصول جدید چه بازخوردهایی داشتیم؟»
  • «یه گزارش خلاصه برای جلسه فردا آماده کن»
  • «به تیم فروش بگو کمپین جدید شروع شده»
  • «توی مستندات داخلی بگرد ببین پالیسی مرخصی چیه»

هر کدوم از اینها الان به یه ابزار جداگانه نیاز داره: داشبورد مالی، CRM، ایمیل، پیام‌رسان، ویکی داخلی. ده تا تب باز، ده تا پسورد، ده تا رابط کاربری متفاوت.

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

تشبیه
یه دستیار اداری فوق‌العاده رو تصور کن. یه نفر که هم بلده توی سیستم مالی بگرده، هم ایمیل بزنه، هم مستندات شرکت رو حفظه، هم CRM رو بلده. تو فقط بهش می‌گی «می‌خوام این کار انجام بشه» و اون خودش همه مراحل رو انجام می‌ده. ما داریم نسخه دیجیتال این دستیار رو طراحی می‌کنیم — با MCP.

معماری سیستم

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

لایه ۱: MCP Serverها (مغزهای تخصصی)

هر MCP Server یه تخصص داره. مثل بخش‌های مختلف یه شرکت، هر کدوم یه کار بلدن و خوب بلدن:

  • Database Server: وصل به دیتابیس شرکت — فروش، مشتریان، محصولات. هر وقت نیاز به عدد و آمار باشه، این سرور جواب می‌ده.
  • RAG Server: جستجو توی مستندات داخلی — پالیسی‌ها، گزارش‌ها، آموزش‌ها. هر وقت سوال «این قانون شرکت چیه؟» پیش بیاد، این سرور کار می‌کنه.
  • Communication Server: ارسال پیام — ایمیل، Slack، SMS. هر وقت قراره اطلاعاتی به کسی برسه، این سرور وارد عمل می‌شه.
  • Analytics Server: تحلیل داده و ساخت گزارش. داده خام رو تبدیل به insight می‌کنه.
نکته
لازم نیست همه این سرورها رو خودت از صفر بسازی. برای خیلی از اینها MCP Serverهای آماده وجود داره. مثلاً برای PostgreSQL، Slack و GitHub سرورهای رسمی هست. هنر تو اینه که بدونی کدوم سرورها رو ترکیب کنی و چطور کنارشون یه سرور اختصاصی برای نیازهای خاصت بسازی.

لایه ۲: AI Client (مغز مرکزی)

این همون مدل زبانی هست (مثل Claude) که به همه MCP Serverها وصله و نقش هماهنگ‌کننده رو داره. وقتی تو یه سوال می‌پرسی، این مدل:

  1. درخواستت رو تحلیل می‌کنه و می‌فهمه چی می‌خوای
  2. تصمیم می‌گیره به کدوم سرور(ها) مراجعه کنه
  3. اطلاعات رو از سرورهای مختلف جمع می‌کنه
  4. داده‌ها رو ترکیب و تحلیل می‌کنه
  5. نتیجه نهایی رو به شکلی که بخوای ارائه می‌ده

نکته مهم اینه که مدل زبانی خودش تشخیص می‌ده کدوم ابزار لازمه. تو نیازی نداری workflow رو از قبل تعریف کنی. فقط ابزارها رو خوب توضیح بده (description واضح) و مدل بقیه کار رو انجام می‌ده. این همون مفهوم AI Agent هست — مدل زبانی به‌عنوان یه تصمیم‌گیرنده هوشمند عمل می‌کنه.

لایه ۳: رابط کاربری (Frontend)

این می‌تونه یه چت‌بات وب، یه بات تلگرام، یه اسلک‌بات، یا حتی یه داشبورد باشه. مهم اینه که کاربر بتونه با زبان طبیعی درخواستش رو بگه. زیبایی این معماری اینه که رابط کاربری هیچ ربطی به MCP Serverها نداره — فقط با مدل زبانی حرف می‌زنه و مدل بقیه کار رو انجام می‌ده.

طراحی Database Server

بذار اولین سرور رو با جزئیات بیشتری ببینیم. Database Server قراره به دیتابیس شرکت وصل بشه و ابزارهایی برای دسترسی به اطلاعات فراهم کنه.

Toolهای مورد نیاز:

// ابزارهای Database Server
tools: [
  {
    name: "query_sales",
    description: "Get sales data for a given period",
    parameters: { start_date, end_date, product_id? }
  },
  {
    name: "get_customer_info",
    description: "Get customer details by ID or name",
    parameters: { customer_id?, name? }
  },
  {
    name: "get_product_stats",
    description: "Product performance statistics",
    parameters: { product_id, period }
  }
]

نکته کلیدی اینه که ابزارها باید read-only باشن (حداقل در شروع). نمی‌خوای AI بدون تأیید تو، توی دیتابیس تغییر ایجاد کنه. این همون اصل Least Privilege هست که توی قسمت امنیت یاد گرفتیم.

هشدار
هرگز به AI دسترسی مستقیم SELECT * یا اجرای SQL دلخواه نده. ابزارها رو محدود و مشخص تعریف کن. AI باید فقط از طریق ابزارهای از پیش تعریف‌شده به داده دسترسی داشته باشه. یادت باشه: مدل زبانی ممکنه prompt injection بشه و سعی کنه SQL مخرب اجرا کنه.

Resources برای داده‌های ثابت:

بعضی اطلاعات تغییر نمی‌کنن (یا خیلی کم تغییر می‌کنن) و نیازی به query نیست. اینها رو به‌صورت Resource تعریف می‌کنیم:

resources: [
  {
    uri: "db://schema/tables",
    name: "Database Schema",
    description: "List of all tables and their columns"
  },
  {
    uri: "db://config/products",
    name: "Product Catalog",
    description: "Current product list with categories"
  }
]

با این کار، مدل زبانی از اول می‌دونه ساختار دیتابیس چیه و نیازی نیست هر بار ازت بپرسه. این هم عملکرد رو بهتر می‌کنه و هم هزینه توکن رو کم.

طراحی RAG Server

سرور دوم ما برای جستجو توی مستندات داخلی شرکته. اگه سری RAG از صفر تا پروداکشن رو خونده باشی، با مفهوم Retrieval-Augmented Generation آشنایی. اینجا داریم RAG رو به‌صورت یه MCP Server پیاده‌سازی می‌کنیم تا هر کلاینتی بتونه ازش استفاده کنه.

چرا RAG به‌عنوان MCP Server؟

خیلی ساده: چون می‌خوای همون RAG رو از هر کلاینتی استفاده کنی. فرقی نمی‌کنه کاربر از چت وب استفاده می‌کنه یا از Slack یا از CLI. RAG Server یه بار ساخته می‌شه و همه بهش وصل می‌شن. این همون مزیت «یه بار بساز، همه‌جا استفاده کن» هست که از قسمت اول سری باهاش آشنا شدی.

// ابزارهای RAG Server
tools: [
  {
    name: "search_documents",
    description: "Search company docs using semantic search",
    parameters: { query, department?, doc_type? }
  },
  {
    name: "get_document",
    description: "Get full content of a specific document",
    parameters: { document_id }
  }
]

// پرامپت‌های از پیش تعریف‌شده
prompts: [
  {
    name: "summarize_policy",
    description: "Summarize a company policy in plain language",
    arguments: { policy_name }
  }
]
تشبیه
RAG Server مثل یه کتابدار دیجیتال هست. وقتی سوالی داری، کتابدار بین همه مستندات می‌گرده، مرتبط‌ترین‌ها رو پیدا می‌کنه و بهت می‌ده. تفاوتش با جستجوی ساده (مثل Ctrl+F) اینه که معنی سوالت رو می‌فهمه، نه فقط کلمات رو مچ می‌کنه. مثلاً اگه بپرسی «قوانین مرخصی» می‌تونه سندی رو پیدا کنه که عنوانش «سیاست‌های HR» هست ولی محتواش درباره مرخصیه.

طراحی Communication Server

این سرور مسئول ارتباطاته. هر جا قراره پیامی فرستاده بشه — ایمیل، Slack، SMS، اعلان — این سرور وارد عمل می‌شه:

tools: [
  {
    name: "send_email",
    description: "Send email (requires human approval)",
    parameters: { to, subject, body, cc? }
  },
  {
    name: "send_slack_message",
    description: "Send a Slack message to a channel or user",
    parameters: { channel, message }
  },
  {
    name: "create_task",
    description: "Create a task in project management tool",
    parameters: { title, assignee, due_date?, priority? }
  }
]
مهم
سرور ارتباطات حساس‌ترین سرور سیستمه چون تأثیر بیرونی داره. ابزارهای دیگه فقط داده می‌خونن، ولی این سرور با دنیای بیرون ارتباط برقرار می‌کنه. حتماً تأیید انسانی (Human-in-the-loop) رو فعال کن. AI نباید بدون تأیید تو ایمیل بفرسته یا پیام بده. یه مرحله تأیید بذار: «می‌خوام این ایمیل رو بفرستم، موافقی؟»

جادوی ترکیب — یه سناریوی واقعی

حالا بذار ببینیم وقتی همه سرورها کنار هم کار می‌کنن، چه اتفاقی می‌افته. فرض کن از دستیارت می‌پرسی:

«گزارش فروش ماه گذشته رو خلاصه کن و اگه از هدف عقب هستیم، نتیجه رو برای تیم فروش بفرست.»

یه درخواست ساده به نظر می‌رسه، ولی دستیار هوشمند پشت صحنه این مراحل رو طی می‌کنه:

  1. فهم درخواست: مدل زبانی تشخیص می‌ده که به داده فروش، اهداف فروش و احتمالاً ارسال پیام نیاز داره
  2. Database Server → query_sales: داده فروش ماه گذشته رو با جزئیات می‌گیره
  3. Database Server → get_product_stats: آمار هر محصول رو هم اضافه می‌کنه تا بفهمه کجا قوی و کجا ضعیف بودیم
  4. RAG Server → search_documents: اهداف فروش ماهانه رو از مستندات داخلی پیدا می‌کنه (برای مقایسه با عملکرد واقعی)
  5. تحلیل و تصمیم: مدل زبانی اعداد فروش رو با اهداف مقایسه می‌کنه — آیا عقب هستیم؟
  6. تولید گزارش: یه خلاصه خوانا و حرفه‌ای از وضعیت می‌نویسه
  7. Communication Server → send_slack_message: اگه عقب هستیم، گزارش رو آماده ارسال به کانال تیم فروش می‌کنه (بعد از تأیید تو)

هفت مرحله. ولی تو فقط یه جمله گفتی. این قدرت ترکیب MCP Serverهاست. هر سرور یه تکه از پازل رو حل می‌کنه و مدل زبانی تکه‌ها رو کنار هم می‌ذاره.

نکته
توجه کن که مدل یه تصمیم شرطی هم گرفت: «اگه عقب هستیم، بفرست.» این همون قابلیت Agent‌هاست — مدل فقط ابزار صدا نمی‌زنه، فکر می‌کنه و بر اساس نتیجه تصمیم می‌گیره.

پیکربندی کلاینت

برای اینکه همه سرورها به یه کلاینت وصل بشن، پیکربندی این‌شکلی می‌شه. توجه کن چطور سرورهای لوکال و ریموت کنار هم قرار می‌گیرن:

{
  "mcpServers": {
    "database": {
      "command": "node",
      "args": ["./servers/database/index.js"],
      "env": {
        "DB_HOST": "localhost",
        "DB_NAME": "company_db"
      }
    },
    "rag": {
      "url": "http://rag-server:3001/mcp",
      "headers": {
        "Authorization": "Bearer ${RAG_API_KEY}"
      }
    },
    "communication": {
      "url": "http://comm-server:3002/mcp",
      "headers": {
        "Authorization": "Bearer ${COMM_API_KEY}"
      }
    }
  }
}

دقت کن: Database Server به‌صورت لوکال (stdio) اجراست چون مستقیم به دیتابیس نیاز داره و نباید ترافیکش از شبکه رد بشه. ولی RAG و Communication سرورها ریموت (HTTP) هستن چون ممکنه روی سرورهای جداگانه باشن یا چند کلاینت همزمان بهشون وصل باشن.

مدیریت خطا و بازگشت

توی سیستم‌های واقعی، همه‌چیز همیشه خوب کار نمی‌کنه. سرور ممکنه down باشه، دیتابیس کند جواب بده، یا API بیرونی خطا برگردونه. یه سیستم خوب باید برای این شرایط آماده باشه:

۱. Timeout مناسب

هر ابزار باید یه timeout مشخص داشته باشه. اگه دیتابیس ۳۰ ثانیه جواب نداد، بهتره خطا برگردونی تا اینکه کاربر forever منتظر بمونه. تجربه کاربری بد از نبود پاسخ بدتره.

۲. Fallback هوشمند

اگه یه سرور در دسترس نیست، دستیار باید بتونه بگه: «الان نمی‌تونم به داده فروش دسترسی پیدا کنم. می‌خوای بعداً دوباره تلاش کنم؟» نه اینکه کلاً crash کنه. این یه تفاوت بزرگ بین یه نمونه آزمایشی و یه محصول واقعیه.

۳. Retry با backoff

برای خطاهای موقتی (مثل network timeout)، یه retry با exponential backoff بذار. اولین تلاش بعد از ۱ ثانیه، دومی بعد از ۲ ثانیه، سومی بعد از ۴ ثانیه. بعد از سه بار، دست از تلاش بردار و به کاربر بگو.

نکته
یه الگوی خوب اینه که هر MCP Server یه health_check tool داشته باشه. کلاینت قبل از شروع کار می‌تونه health همه سرورها رو چک کنه و اگه سروری down بود، از قبل به کاربر بگه: «دیتابیس الان در دسترس نیست، فقط می‌تونم توی مستندات جستجو کنم.»

گسترش مرحله به مرحله

یه اشتباه خیلی رایج اینه که بخوای از روز اول همه سرورها رو بسازی و همه قابلیت‌ها رو داشته باشی. نه! مرحله به مرحله پیش برو. هر فاز باید باثبات و تست‌شده باشه قبل از اینکه بری سراغ فاز بعدی:

فاز ۱: فقط Database Server (هفته ۱-۲)

با یه سرور شروع کن. فقط دیتابیس. سه‌چهار ابزار ساده: خوندن فروش، اطلاعات مشتری، آمار محصول. مطمئن شو درست کار می‌کنه، خطاها handle شدن، و امنیت رعایت شده. خودت هر روز باهاش کار کن.

فاز ۲: اضافه کردن RAG (هفته ۳-۴)

وقتی Database Server باثبات شد، RAG Server رو اضافه کن. حالا دستیارت هم از دیتابیس می‌خونه و هم توی مستندات جستجو می‌کنه. ببین مدل چطور بین دو سرور تصمیم می‌گیره. آیا درست انتخاب می‌کنه؟ توضیحات ابزارها واضحه؟

فاز ۳: ارتباطات (هفته ۵-۶)

Communication Server رو اضافه کن. ولی حتماً با Human-in-the-loop! هیچ پیامی بدون تأیید تو فرستاده نشه. این فاز رو با تعداد کمی کاربر تست کن.

فاز ۴: اتوماسیون (بعد از ۲ ماه)

وقتی سیستم رو خوب شناختی و بهش اعتماد پیدا کردی، می‌تونی بعضی workflowها رو خودکار کنی. مثلاً «هر صبح ساعت ۸ گزارش فروش دیروز رو خلاصه کن و توی اسلک بفرست.» ولی هنوزم برای ایمیل‌های مهم، تأیید انسانی رو نگه دار.

تشبیه
ساخت این سیستم مثل ساختن خونه‌ست. اول فونداسیون (Database Server)، بعد دیوارها (RAG)، بعد تأسیسات برق و لوله‌کشی (Communication)، و آخر سر اتوماسیون خونه هوشمند. اگه بخوای همه رو همزمان بسازی، خونه خراب می‌شه.

تست و اعتبارسنجی

قبل از اینکه سیستم رو به بقیه تیم بدی، خودت حسابی تستش کن. این چک‌لیست کمکت می‌کنه:

  • تست هر سرور جداگانه: مطمئن شو هر سرور به‌تنهایی درست کار می‌کنه — ورودی‌های مختلف بده، خروجی رو بررسی کن
  • تست ترکیبی: سناریوهایی طراحی کن که چند سرور رو همزمان درگیر می‌کنه (مثل همون مثال گزارش فروش)
  • تست خطا: یه سرور رو عمداً خاموش کن و ببین سیستم چطور واکنش نشون می‌ده. آیا پیام خطای واضح می‌ده؟
  • تست امنیت: سعی کن از طریق AI به داده‌هایی دسترسی پیدا کنی که نباید — prompt injection تست کن
  • تست با کاربر واقعی: یه نفر غیرفنی رو بذار باهاش کار کنه و ببین کجاها گیج می‌شه یا نتیجه غیرمنتظره می‌گیره

مروری بر کل سری

بذار یه نگاه کلی به مسیری که طی کردیم بندازیم:

  1. MCP چیه و چرا مهمه؟ — مفهوم پروتکل، مشکل M×N، و چرا MCP مثل USB برای AI هست
  2. نصب و راه‌اندازی اولین MCP Server — نصب عملی، اولین اجرا و اتصال به Claude Desktop
  3. ساخت MCP Server اختصاصی — ساخت سرور از صفر با TypeScript SDK
  4. Resources و Prompts — داده‌های فقط‌خواندنی و الگوهای تعامل
  5. اتصال به Claude و مدل‌های دیگه — پیکربندی کلاینت‌های مختلف
  6. امنیت و بهترین شیوه‌ها — Least Privilege، اعتبارسنجی ورودی، sandbox
  7. MCP در پروداکشن — Docker، مانیتورینگ، مقیاس‌پذیری
  8. پروژه نهایی (همین قسمت) — ترکیب همه مفاهیم در یه سیستم واقعی
یه حرف صادقانه
MCP هنوز تکنولوژی نسبتاً جوانیه و داره سریع تکامل پیدا می‌کنه. بعضی از ابزارها و روش‌هایی که امروز بهترین هستن، ممکنه چند ماه دیگه جاشون رو به روش‌های بهتری بدن. ولی مفاهیم پایه‌ای که توی این سری یاد گرفتی — معماری کلاینت-سرور، طراحی ابزار خوب، امنیت، تست — اینها تغییر نمی‌کنن و توی هر تکنولوژی بعدی هم به دردت می‌خورن.

قدم‌های بعدی

حالا که مفاهیم MCP رو یاد گرفتی، چند مسیر جذاب پیش روته:

عمیق‌تر شو:

  • اگه می‌خوای بیشتر درباره ساخت AI Agent یاد بگیری — سری Agentها رو بخون. MCP بدون Agent فقط نصف قدرتشه.
  • اگه RAG Server ساختن برات جذاب بود — سری RAG از صفر تا پروداکشن رو ببین. اونجا خیلی عمیق‌تر وارد بحث embedding، vector store و ارزیابی می‌شیم.
  • اگه می‌خوای مدل رو روی دیتای خودت تنظیم کنی — سری Fine-tuning عملی رو بخون.

عملی کن:

  • یه MCP Server ساده برای یه نیاز واقعی خودت بساز — مثلاً دسترسی به API شرکتت
  • از سرورهای آماده جامعه MCP استفاده کن و ببین چطور ترکیبشون نتیجه می‌ده
  • توی ریپوزیتوری رسمی MCP مشارکت کن — حتی یه باگ‌فیکس کوچیک هم ارزشمنده

منابع مفید:

جمع‌بندی

MCP یه تغییر بنیادی در نحوه تعامل AI با دنیای واقعیه. قبلاً مدل‌های زبانی توی یه حباب بودن — هوشمند ولی ناتوان از انجام کار واقعی. حالا با MCP می‌تونن به هر ابزار و هر منبع داده‌ای وصل بشن. و مهم‌تر از همه، این اتصال استاندارد و امن هست — نه یه هک موقتی.

توی این سری یاد گرفتی که MCP فقط یه API wrapper نیست. یه پروتکل کامله با Tools، Resources و Prompts. یاد گرفتی سرور بسازی، به کلاینت‌ها وصلش کنی، امنش نگه داری و به پروداکشن ببری. و الان دیدی که چطور می‌شه چند سرور رو ترکیب کنی و یه دستیار هوشمند واقعی طراحی کنی.

امیدوارم این سری برات مفید بوده باشه. اگه سوالی داری یا می‌خوای درباره پیاده‌سازی MCP توی کسب‌وکارت صحبت کنیم، خوشحال می‌شم باهات صحبت کنم.

نظرات

هنوز نظری ثبت نشده. اولین نفر باشید!

نظر خود را بنویسید