Model Context Protocol یا به اختصار MCP، یک استاندارد باز برای اتصال مدل‌های زبانی به ابزارها، داده‌ها و سرویس‌های بیرونی است که با تعریف یک رابط یکپارچه، خلأ میان انتزاع چارچوب‌های برنامه‌نویسی و اتصال‌های اختصاصی را پر می‌کند و برای معماران سامانه‌های هوش مصنوعی به یک انتخاب استراتژیک تبدیل شده است.

هرچه سامانه‌های مبتنی بر عامل‌های مبتنی بر LLM پیچیده‌تر می‌شوند، نیاز به اتصال آن‌ها به دنیای بیرون بیشتر می‌شود. مدل زبانی به‌تنهایی نمی‌تواند به پایگاه داده، فایل سیستم، سرویس‌های وب یا ابزارهای داخلی سازمان دسترسی داشته باشد. تا پیش از MCP، هر اتصال به‌صورت اختصاصی نوشته می‌شد و همین موضوع باعث می‌شد هر عامل جدید نیازمند کد اتصال جدید باشد. MCP این اتصال را به یک رابط استاندارد تبدیل می‌کند و اجازه می‌دهد یک سرور MCP به‌طور هم‌زمان توسط چند کلاینت مستقل مصرف شود. در این راهنما، ابتدا خلأ معماری‌ای که MCP پر می‌کند بررسی می‌شود، سپس اجزای پروتکل، تفاوت آن با رویکردهای پیشین، الگوهای پیاده‌سازی، کاربردهای واقعی، ملاحظات امنیتی و انتخاب بین MCP و RAG در سطح مهندسی تحلیل می‌شود.

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

خلأ معماری که MCP پر می‌کند

در معماری سنتی سامانه‌های هوش مصنوعی، اتصال مدل به دنیای بیرون به سه شکل انجام می‌شد. شکل اول، کد اختصاصی درون خود برنامه بود؛ برای هر ابزار، تابعی نوشته می‌شد و مدل با Function Calling آن را فراخوانی می‌کرد. شکل دوم، استفاده از Pluginهای چارچوب‌های برنامه‌نویسی مثل LangChain بود که برای ابزارهای پرکاربرد، اتصال آماده ارائه می‌کردند. شکل سوم، نوشتن سرویس‌های میانی (middleware) که هر کدام رابط اختصاصی خود را داشتند.

هر سه رویکرد محدودیت‌های مشخصی دارند. رویکرد اول برای پروژه‌های کوچک قابل قبول است اما در پروژه‌های چندعاملی به تکرار کد و پیچیدگی نگهداری می‌انجامد. رویکرد دوم وابستگی به چارچوب ایجاد می‌کند و اگر تیم تصمیم بگیرد چارچوب را عوض کند، باید همه اتصال‌ها را بازنویسی کند. رویکرد سوم معمولاً استاندارد مشخصی ندارد و هر تیم آن را به سلیقه خود پیاده می‌کند.

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

هر استانداردی که در لایه اتصال شکل بگیرد، هزینه نگهداری سامانه‌های چندعاملی را به‌طور چشمگیری کاهش می‌دهد.

نکته مهم این است که MCP جایگزین چارچوب‌هایی مثل LangChain یا LlamaIndex نیست. این پروتکل در لایه اتصال کار می‌کند و در کنار چارچوب‌های برنامه‌نویسی قرار می‌گیرد. اگر به این چارچوب‌ها علاقه‌مند هستید، مطلب لنگ‌چین برای پرامپت نویسی چه امکاناتی دارد؟ به تفصیل به قابلیت‌های آن پرداخته است.

Model Context Protocol چیست و چگونه کار می‌کند

MCP یک پروتکل باز است که نحوه تبادل پیام میان مدل زبانی و ابزارهای بیرونی را استاندارد می‌کند. تعریف رسمی این پروتکل در Model Context Protocol قابل مشاهده است. هسته اصلی MCP بر سه مفهوم بنیان گذاشته شده است: Resource، Tool و Prompt. هر کدام از این سه مفهوم، یک نوع داده یا قابلیت مشخص را توصیف می‌کند.

Resource در MCP به داده‌های خواندنی اشاره دارد که مدل می‌تواند به آن‌ها دسترسی داشته باشد؛ مانند فایل، رکورد پایگاه داده یا سند. Resourceها معمولاً با URI مشخص می‌شوند و مدل می‌تواند درخواست خواندن آن‌ها را ارسال کند. Tool به عملیاتی اشاره دارد که مدل می‌تواند اجرا کند؛ مانند ارسال ایمیل، ساخت فایل یا فراخوانی API بیرونی. Toolها معمولاً با پارامترهای ورودی و خروجی مشخص تعریف می‌شوند. Prompt در این پروتکل به قالب‌های آماده‌ای اشاره دارد که سرور می‌تواند ارائه کند تا کلاینت آن‌ها را برای مدل به‌کار ببرد. این سه مفهوم، ساختاری منسجم برای اتصال مدل به دنیای بیرون فراهم می‌کنند.

ارتباط بین کلاینت و سرور MCP بر پایه JSON-RPC انجام می‌شود. JSON-RPC یک پروتکل ساده و بالغ برای فراخوانی از راه دور است که در آن درخواست‌ها و پاسخ‌ها به فرمت JSON تبادل می‌شوند. انتخاب JSON-RPC به‌عنوان پایه ارتباطی، هم سادگی پیاده‌سازی را فراهم می‌کند و هم سازگاری با ابزارهای موجود را. این انتخاب همچنین باعث می‌شود MCP به‌راحتی روی هر بستر ارتباطی (stdio، HTTP، WebSocket) قابل استفاده باشد.

الگوهای انتقال

MCP سه الگوی انتقال اصلی را پشتیبانی می‌کند. الگوی استاندارد (stdio) که در آن سرور به‌عنوان یک فرآیند محلی اجرا می‌شود و ارتباط از طریق ورودی و خروجی استاندارد انجام می‌شود. این الگو برای ابزارهای توسعه‌دهنده که روی ماشین محلی اجرا می‌شوند مناسب است. الگوی SSE (Server-Sent Events) که در آن سرور از راه دور اجرا می‌شود و ارتباط یک‌طرفه از سرور به کلاینت برای رویدادها و درخواست‌های کلاینت به سرور از طریق HTTP انجام می‌شود. الگوی Streamable HTTP که جدیدتر است و امکان ارتباط دوطرفه پیوسته را روی HTTP فراهم می‌کند.

اجزای اصلی پروتکل MCP

پروتکل MCP از چند مؤلفه تشکیل شده که هر کدام وظیفه مشخصی دارند. درک این مؤلفه‌ها، برای پیاده‌سازی درست ضروری است.

Client و Server

کلاینت MCP بخشی است که مدل زبانی یا عاملی که آن را مصرف می‌کند را به سرور متصل می‌کند. کلاینت مسئولیت مدیریت اتصال، ارسال درخواست‌ها و دریافت پاسخ‌ها را بر عهده دارد. سرور MCP بخشی است که یک ابزار یا داده مشخص را ارائه می‌دهد. هر سرور می‌تواند چند Resource، چند Tool و چند Prompt تعریف کند. تفکیک نقش کلاینت و سرور، معماری روشنی برای توسعه‌دهندگان ایجاد می‌کند.

Resources

Resourceها داده‌هایی هستند که مدل می‌تواند به آن‌ها دسترسی داشته باشد. Resource معمولاً با یک URI مشخص می‌شود و می‌تواند متن، تصویر، داده ساختاریافته یا هر نوع دیگری باشد. یکی از نکات ظریف در طراحی Resource، تعریف سطح دسترسی آن است. اگر Resource آزادانه در اختیار هر کلاینت قرار بگیرد، ریسک افشای داده وجود دارد. به همین دلیل، در طراحی حرفه‌ای، Resourceها باید با سطح دسترسی دقیق تعریف شوند.

Tools

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

Prompts

Promptها در MCP قالب‌های آماده‌ای هستند که سرور در اختیار کلاینت قرار می‌دهد. این قالب‌ها می‌توانند شامل متغیرهایی باشند که در زمان فراخوانی توسط کلاینت پر می‌شوند. مزیت این طراحی، تمرکز دانش تخصصی هر دامنه در خود سرور است. سرور مرتبط با یک حوزه خاص، بهترین قالب پرامپت برای آن حوزه را ارائه می‌دهد، بدون آنکه کلاینت نیازی به شناخت آن داشته باشد.

Sampling و Roots

Sampling یکی از قابلیت‌های MCP است که به سرور اجازه می‌دهد در فرآیند تصمیم‌گیری، از مدل مستقر در کلاینت درخواست تولید کند. این قابلیت به سرور اجازه می‌دهد بدون داشتن مدل مستقل، از قدرت مدل کلاینت بهره ببرد. Roots مفهوم دیگری است که به سرور اجازه می‌دهد مرزهای سیستم فایل را که کلاینت می‌تواند به آن دسترسی داشته باشد، بشناسد. این دو قابلیت، انعطاف MCP را در سناریوهای واقعی افزایش می‌دهند.

تفاوت MCP با APIها، Pluginها و Function Calling

یکی از پرسش‌های رایج این است که MCP چه تفاوتی با APIهای سنتی دارد. در نگاه اول، هر دو امکان دسترسی به قابلیت‌های بیرونی را فراهم می‌کنند، اما تفاوت‌های بنیادین وجود دارد. APIهای سنتی برای مصرف مستقیم توسط کد طراحی شده‌اند و برای استفاده از آن‌ها، برنامه‌نویس باید بداند چه Endpointهایی وجود دارد و هر کدام چه پارامترهایی می‌پذیرد. MCP این اطلاعات را به‌صورت خودتوصیف (self-describing) ارائه می‌دهد. مدل می‌تواند در زمان اجرا کشف کند که چه Toolها و Resourceهایی در دسترس هستند و نیازی به کدگذاری اولیه ندارد.

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

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

الگوهای پیاده‌سازی سرور MCP

پیاده‌سازی سرور MCP می‌تواند به چند الگوی اصلی تقسیم شود. انتخاب الگو بر اساس نوع ابزار و مقیاس سامانه انجام می‌شود.

سرور محلی با stdio

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

سرور راه دور با HTTP

برای ابزارهایی که باید از چند سامانه در دسترس باشند، اجرای سرور به‌عنوان یک سرویس HTTP مناسب‌تر است. این الگو امکان اشتراک‌گذاری سرور میان چند کلاینت و مقیاس‌پذیری بهتر را فراهم می‌کند. چالش اصلی این الگو، مدیریت احراز هویت و کنترل دسترسی است. در طراحی حرفه‌ای، سرور MCP راه دور باید از مکانیزم‌های احراز هویت استاندارد (OAuth، JWT) پشتیبانی کند.

سرور ترکیبی و چندلایه

در سامانه‌های پیچیده، می‌توان از ترکیب چند سرور استفاده کرد. برای مثال، یک سرور مسئول دسترسی به پایگاه داده، یک سرور مسئول ارتباط با سرویس‌های بیرونی، و یک سرور مسئول اجرای دستورات سیستم. کلاینت می‌تواند در زمان اجرا کشف کند که کدام Tool در کدام سرور است و درخواست را به سرور مناسب هدایت کند. این معماری، انعطاف و مقیاس‌پذیری بالایی ایجاد می‌کند.

کاربردهای عملی MCP در پروژه‌های واقعی

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

کاربرد دوم، اتصال ابزارهای توسعه‌دهنده به مدل است. برای مثال، یک سرور MCP می‌تواند به مخزن Git، سیستم مدیریت پروژه یا ابزار CI/CD متصل باشد و به مدل اجازه دهد در فرآیند توسعه، از این ابزارها استفاده کند. این نوع یکپارچگی در ابزارهای مدرن کدنویسی با هوش مصنوعی به‌طور گسترده دیده می‌شود.

کاربرد سوم، ساخت عامل‌های تخصصی دامنه‌محور است. برای مثال، یک سرور MCP می‌تواند به‌طور اختصاصی برای حوزه حقوقی طراحی شود و ابزارهای تحلیل قرارداد، جستجو در پرونده‌ها و استخراج شرط‌های مهم را ارائه دهد. مدل زبانی با اتصال به این سرور، به یک دستیار حقوقی تخصصی تبدیل می‌شود. توضیح جامع‌تر در مورد کاربرد MCP در عامل‌های پیچیده در مطلب عامل‌های Deep Research برای حل پرسش‌های پیچیده آمده است.

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

MCP ابزارها را از حالت اختصاصی به حالت اشتراکی تبدیل می‌کند و همین ویژگی، اقتصاد ساخت سامانه‌های هوش مصنوعی را تغییر می‌دهد.

امنیت، حریم خصوصی و مدیریت دسترسی

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

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

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

دسته سوم، سوءاستفاده از Toolهای حساس است. اگر سرور MCP دسترسی به عملیاتی مثل حذف فایل، اجرای دستور یا ارسال ایمیل داشته باشد، هر خطای مدل یا دستکاری مخرب می‌تواند خسارت جدی ایجاد کند. راه‌حل این مسئله، طراحی Toolها به‌صورت عملیات کوچک و محدود، به‌جای عملیات گسترده، و همچنین افزودن تأیید انسانی برای عملیات حساس است.

مفهوم هوش مصنوعی قابل اعتماد در این بستر اهمیت مستقیم پیدا می‌کند. اگر به اصول کلی آن علاقه‌مند هستید، مطلب هوش مصنوعی قابل اعتماد مفاهیم پایه را ارائه می‌دهد.

انتخاب بین MCP، RAG و ابزارهای بومی

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

RAG برای دسترسی به دانش غیرساختاریافته مناسب است. اگر نیاز اصلی سامانه، پاسخ به پرسش بر اساس مجموعه‌ای از اسناد است، RAG انتخاب درستی است. توضیح کامل این الگو در مطلب RAG چیست؟ ارائه شده است. RAG داده را در قالب قطعات متنی (chunks) بازیابی و در پرامپت تزریق می‌کند و برای سامانه‌هایی که فقط به خواندن داده نیاز دارند، راه‌حل ساده‌تر و مقرون‌به‌صرفه‌تری است.

MCP برای تعامل با ابزارها و عملیات مناسب است. اگر سامانه نیاز دارد نه فقط داده بخواند بلکه عملیاتی انجام دهد (ارسال ایمیل، ثبت سفارش، اجرای دستور)، MCP انتخاب بهتر است. در واقع، RAG و MCP مکمل یکدیگرند و در سامانه‌های پیچیده، هر دو در کنار هم استفاده می‌شوند. RAG برای دسترسی به دانش، MCP برای تعامل با عملیات.

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

پرسش‌های پرتکرار درباره Model Context Protocol

آیا MCP فقط برای مدل‌های خاصی کار می‌کند؟

خیر. MCP یک پروتکل باز است و مستقل از مدل طراحی شده. هر مدل یا سامانه‌ای که بتواند با JSON-RPC ارتباط برقرار کند، می‌تواند به‌عنوان کلاینت MCP عمل کند. در عمل، این پروتکل در ابزارهای متنوعی پیاده‌سازی شده و توسط چند شرکت بزرگ پشتیبانی می‌شود.

آیا استفاده از MCP وابستگی به فروشنده ایجاد می‌کند؟

یکی از اهداف اصلی MCP، کاهش وابستگی به فروشنده است. برخلاف Pluginهای اختصاصی که به یک چارچوب گره می‌خورند، سرور MCP مستقل است و می‌تواند در چند سامانه مصرف شود. این استقلال، ریسک وابستگی بلندمدت را به‌طور چشمگیری کاهش می‌دهد.

چطور یک سرور MCP را در پروژه خود پیاده‌سازی کنیم؟

پیاده‌سازی سرور MCP با استفاده از SDKهای رسمی که برای زبان‌های برنامه‌نویسی مختلف ارائه شده، ساده است. مسیر اصلی این است: تعریف Toolها و Resourceها با اسکیمای مشخص، پیاده‌سازی منطق اجرای هر Tool، و راه‌اندازی سرور روی یکی از الگوهای انتقال (stdio یا HTTP). برای شروع، الگوی stdio ساده‌ترین گزینه است.

آیا MCP جایگزین APIهای سنتی می‌شود؟

خیر. MCP در لایه بالاتر از APIهای سنتی قرار می‌گیرد و از آن‌ها برای اتصال به سرویس‌های بیرونی استفاده می‌کند. سرور MCP در نهایت برای اجرای Toolهای خود، APIهای زیرین را فراخوانی می‌کند. بنابراین MCP جانشین APIها نیست، بلکه لایه انتزاعی روی آن‌هاست.

چه نوع Toolهایی برای MCP مناسب‌ترند؟

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

چطور MCP را با سامانه‌های موجود سازمان یکپارچه کنیم؟

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

نگاه معماری در سطح مهندسی ارشد

در سطح مهندسی ارشد، MCP یک تصمیم معماری است که سه محور را هم‌زمان تحت تأثیر قرار می‌دهد: پایداری سامانه، امنیت و اقتصاد نگهداری. تصمیم‌های این سطح، فراتر از انتخاب SDK و نحوه راه‌اندازی سرور است و به طراحی اکوسیستم پیرامون MCP مربوط می‌شود.

نخستین محور، طراحی لایه کشف (discovery) است. در سامانه‌ای که چندین سرور MCP دارد، مدل یا کلاینت باید بتواند در زمان اجرا کشف کند که چه ابزارهایی در دسترس هستند و هر یک چه قابلیتی دارند. طراحی این لایه، شبیه به طراحی سرویس‌های کشف در معماری میکروسرویس است. در پروژه‌های واقعی، نبود این لایه باعث می‌شود هر افزودن Tool جدید نیازمند تغییر در کد کلاینت باشد و این دقیقاً همان چیزی است که MCP تلاش می‌کند از آن جلوگیری کند.

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

محور سوم، طراحی سامانه پایش و ثبت رویداد در سطح MCP است. هر فراخوانی Tool باید ثبت شود، همراه با شناسه کاربر، پارامترهای ورودی، خروجی و زمان اجرا. این لاگ‌ها هم برای دیباگ، هم برای حسابرسی امنیتی و هم برای تحلیل استفاده از ابزارها ضروری هستند. در سامانه‌های بزرگ، این لاگ‌ها به یک خط لوله داده تبدیل می‌شوند که در پایش کیفیت و شناسایی الگوهای سوءاستفاده نقش کلیدی دارند. مبانی MLOps و پایش بلندمدت در مطلب MLOps چیست؟ بررسی شده است.

محور چهارم، طراحی مکانیزم تحمل خطا در سطح پروتکل است. اگر یک سرور MCP از دسترس خارج شود، کلاینت باید بتواند به‌طور خودکار به مسیر جایگزین هدایت شود یا خطا را به‌صورت شفاف گزارش کند. طراحی این لایه نیازمند تعریف سیاست Retry، Circuit Breaker و Timeout مشخص است. در پروژه‌هایی که چند سرور MCP با هم ترکیب می‌شوند، این لایه تفاوت میان سامانه پایدار و سامانه شکننده را می‌سازد.

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

در نهایت، MCP یک زیرساخت است که تصمیم‌های معماری در آن اثر بلندمدت دارند. انتخاب درست در طراحی، به دارایی استراتژیک سازمان تبدیل می‌شود؛ انتخاب نادرست، به بدهی فنی پرهزینه. درک عمیق از مفروضات پروتکل، آگاهی از محدودیت‌های پیاده‌سازی و توانایی طراحی لایه‌های مکمل (کشف، احراز هویت، پایش، تحمل خطا)، تفاوت میان معماران ارشد این حوزه را شکل می‌دهد.

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