سرور MCP چیست؟ پایان دوران جهنم Integration در توسعه اپلیکیشن‌ با AI

حلقه مفقوده در معماری LLMها

تا پیش از این، اتصال یک مدل زبانی (LLM) به داده‌های داخلی شرکت، شبیه به سیم‌کشی ساختمان‌های قدیمی بود، پر از سیم‌های لخت، اتصالات ناامن و کدهای اسپاگتی. به عنوان مهندس نرم‌افزار، ما با مشکل N x M روبرو بودیم. شما می‌خواهید Claude را به دیتابیس Postgres وصل کنید؟ باید یک اسکریپت پایتون بنویسید. می‌خواهید ChatGPT به Slack دسترسی داشته باشد؟ یک Integration دیگر. حالا اگر بخواهید IDE شما (مثلا VS Code) همزمان به GitHub و Jira دسترسی داشته باشد چه؟

نتیجه، انبوهی از “Glue Code” (کد چسب) است که نگهداری آن‌ها کابوس است. هر بار که API یکی از این سرویس‌ها تغییر می‌کند، پایپ‌لاین‌های شما می‌شکنند.

اینجا جایی است که MCP (Model Context Protocol) وارد می‌شود. بیایید تعارفات را کنار بگذاریم؛ MCP ابزاری برای “بهتر چت کردن” نیست. MCP تلاش صنعت برای ایجاد یک استاندارد Open Standard شبیه به USB-C برای مدل‌های هوش مصنوعی است. هدف ساده است: حذف Boilerplate Code و استانداردسازی روشی که مدل‌ها با دنیای بیرون (Data & Tools) ارتباط برقرار می‌کنند.

کالبدشکافی پروتکل (The Protocol Anatomy)

درک MCP نیازمند نگاه به زیر کاپوت آن است. MCP صرفاً یک API نیست؛ یک پروتکل ارتباطی مبتنی بر JSON-RPC 2.0 است که تعاملات stateful بین کلاینت و سرور را مدیریت می‌کند.

معماری MCP از سه بخش اصلی تشکیل شده است:

۱. MCP Host (میزبان)

این همان اپلیکیشن اصلی است که مدل را اجرا می‌کند (مثل Claude Desktop، Zed Editor یا پلتفرم‌های AI داخلی شرکت شما). Host مغز متفکر است که تصمیم می‌گیرد چه زمانی نیاز به اطلاعات خارجی دارد.

۲. MCP Client (کلاینت)

این لایه اتصال‌دهنده است که پروتکل هندشیک (Handshake) و مدیریت پیام‌ها را انجام می‌دهد. کلاینت مسئول حفظ ارتباط با سرور و تبدیل درخواست‌های Host به فرمت استاندارد MCP است.

۳. MCP Server (سرور)

اینجاست که جادو اتفاق می‌افتد. MCP Server یک سرویس سبک است که منابع داده (مانند دیتابیس، فایل سیستم، یا APIهای خارجی) را کپسوله می‌کند. نکته کلیدی اینجاست: سرور MCP هیچ چیزی درباره LLM نمی‌داند. او فقط مجموعه‌ای از منابع (Resources) و ابزارها (Tools) را طبق استاندارد ارائه می‌دهد.

لایه انتقال (Transport Layer)

یکی از هوشمندانه‌ترین بخش‌های معماری MCP، لایه انتقال آن است که از دو حالت پشتیبانی می‌کند:

studio: برای اتصالات محلی (Local). مثلاً وقتی می‌خواهید مدل به فایل‌های روی لپ‌تاپ یا دیتابیس لوکال دسترسی داشته باشد. این یعنی فرآیند به عنوان یک ساب-پروسس اجرا می‌شود و امنیت بسیار بالایی دارد.

SSE (Server-Sent Events): برای اتصالات راه دور (Remote). وقتی سرور MCP شما روی یک کلاستر کوبرنتیز اجرا می‌شود و Host روی سیستم شماست.

چرا MCP از نظر معماری اهمیت دارد؟

چرا ما مهندسان باید به جای استفاده از همان روش‌های قدیمی LangChain یا اسکریپت‌های دستی، به سراغ MCP برویم؟

۱. اصل جداسازی دغدغه‌ها (Separation of Concerns)

در روش‌های سنتی، منطق اتصال به دیتابیس درون کد اپلیکیشن AI تنیده شده بود. با MCP، شما یک بار یک سرور برای “خواندن دیتابیس شرکت” می‌نویسید. حالا هر کلاینتی (چه Claude باشد، چه IDE، چه یک اسکریپت اتوماسیون) می‌تواند بدون دانستن Credentialهای دیتابیس یا نوع درایور SQL، از آن استفاده کند.

۲. امنیت و Sandboxing

این مورد حیاتی است. در پلاگین‌های قدیمی، شما اغلب مجبور بودید کلید API خود را به پلتفرم هوش مصنوعی بدهید. در MCP، کلیدهای API و دسترسی به دیتابیس درون سرور MCP (که تحت کنترل شماست) باقی می‌مانند. مدل فقط می‌تواند توابعی را صدا بزند که شما صراحتاً در لیست Tools تعریف کرده‌اید (Expose). این یعنی کاهش شدید سطح حمله (Attack Surface).

۳. مدیریت کانتکست (Context Efficiency)

به جای اینکه کل لاگ‌های سرور را در پرامپت کپی کنید (و توکن‌های گران‌قیمت را هدر دهید)، MCP به مدل اجازه می‌دهد مثل یک سیستم عامل عمل کند:

مدل لیست فایل‌ها را می‌بیند (ls).

فقط فایل مورد نظر را می‌خواند (cat).

فقط بخش مرتبط را تحلیل می‌کند.این یعنی تعامل RAG-گونه (Retrieval-Augmented Generation) اما استاندارد شده و بدون نیاز به پیاده‌سازی Vector DB برای هر کار ساده‌ای.

کاربردهای واقعی برای مهندسین

بیایید ببینیم در یک روز کاری واقعی، MCP چطور زندگی ما را ساده می‌کند. این‌ها سناریوهایی هستند که همین الان قابل پیاده‌سازی‌اند:

دیباگینگ و DevOps هوشمند

تصور کنید سرور MCPی دارید که به کلاستر Kubernetes دسترسی Read-only دارد.

سناریو: یک Pod کرش کرده است.

تعامل: به جای زدن ۱۰ دستور kubectl، از مدل می‌پرسید: “چرا سرویس Payment در محیط Staging دان شده؟”

عملکرد: مدل از طریق MCP، لاگ‌های کانتینر را می‌خواند، ایونت‌های اخیر K8s را چک می‌کند و به شما می‌گوید: “خطای OOM (Out of Memory) در ساعت ۲:۳۰ رخ داده.”

تعامل با دیتابیس بدون Context Switching

شما در حال کدنویسی هستید و نیاز دارید ساختار جدول Users را بدانید. به جای باز کردن DBeaver یا pgAdmin، مستقیماً در IDE از ایجنت می‌پرسید و او از طریق MCP Server متصل به Postgres، اسکیمای دقیق را برایتان می‌آورد.

تحلیل کد بیس و Git

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

پیاده‌سازی: چطور شروع کنیم؟

پیاده‌سازی یک سرور MCP ساده‌تر از نوشتن یک میکروسرویس REST است. SDKهای رسمی برای TypeScript و Python وجود دارد.

ساختار منطقی یک سرور MCP بر سه پایه استوار است:

Resources (منابع): داده‌هایی که مدل می‌تواند بخواند (مثل فایل‌ها یا رکوردهای دیتابیس). این‌ها معادل GET در HTTP هستند.

Tools (ابزارها): توابعی که مدل می‌تواند اجرا کند (مثل “ارسال پیام به اسلک” یا “ریستارت کردن سرور”). این‌ها معادل POST هستند و باید با احتیاط تعریف شوند.

Prompts (پرامپت‌ها): قالب‌های آماده برای راهنمایی مدل در استفاده از ابزارها.

مثال ذهنی:

اگر بخواهید یک سرور MCP برای هواشناسی بسازید، لازم نیست منطق NLP بنویسید. فقط یک Tool تعریف می‌کنید به نام get_weather که ورودی city می‌گیرد و خروجی JSON برمی‌گرداند. تمام پیچیدگی “فهمیدن اینکه کاربر چه خواسته” توسط Host (مدل زبانی) انجام می‌شود و سرور شما فقط اجراکننده است.

به سمت سیستم‌های Agentic استاندارد

MCP فقط یک ابزار دیگر در جعبه‌ابزار ما نیست؛ بلکه نشان‌دهنده‌ی بلوغ اکوسیستم هوش مصنوعی است. ما داریم از دوران “چت‌بات‌های سرگرم‌کننده” عبور می‌کنیم و وارد دوران “Agentic Systems” می‌شویم. سیستم‌هایی که می‌توانند در دنیای دیجیتال ما عمل کنند، نه اینکه فقط درباره آن حرف بزنند. برای ما مهندسان نرم‌افزار، MCP فرصتی است تا زیرساخت‌های داده‌ای سازمان را یک‌بار برای همیشه استاندارد کنیم و اجازه دهیم لایه هوش مصنوعی (هر مدلی که امروز یا فردا ترند شود) به سادگی و امنیت به آن متصل شود.