پروتکل MCP با معماری بدون وضعیت، مقیاس‌پذیری عامل‌های هوش مصنوعی را تسهیل کرد

اگر یک توسعه‌دهنده هستید که می‌خواهد ابزارهای AI خود را از یک اسکریپت ساده به یک محصول تجاری تبدیل کند، باید بدانید که تفاوت اصلی در نحوه مدیریت خطاها و مقیاس‌پذیری لایه انتقال است. ساخت یک ابزار آماده برای تولید، فراتر از یک فراخوانی تابع موفق است و نیازمند لایه‌ای است که زیر فشار ترافیک بالا فرو نریزد. پروتکل زمینه مدل (Model Context Protocol یا MCP) — که مثل یک مترجم استاندارد است تا هر مدل هوش مصنوعی بتواند بدون یادگیری زبان هر نرم‌افزار، با آن صحبت کند — این زیرساخت گمشده را فراهم می‌کند. این استاندارد باز را آنتروپیک (Anthropic) در نوامبر ۲۰۲۴ معرفی کرد و اکنون تحت نظر بنیاد هوش مصنوعی عامل‌محور (Agentic AI Foundation) وابسته به بنیاد لینوکس توسعه می‌یابد. بر اساس مستندات فنی، نسخه پایدار این پروتکل در ۲۵ نوامبر ۲۰۲۵ منتشر شد، اما معماری آن برای پاسخ به نیازهای محیط تولید همچنان در حال تکامل است.

این چرخش معماری درست زمانی رخ می‌دهد که عامل‌ها از پنجره‌های چت آزمایشی به اپراتورهای فعال سیستم تبدیل می‌شوند. همان‌طور که در تحلیل قبلی ما درباره‌ی ابزارهای طراحی AI که کد تولیدی می‌سازند اشاره کردیم، تمرکز اکنون از «کدی که AI می‌نویسد» به «پروتکلی که AI را به دنیای واقعی متصل می‌کند» تغییر یافته است. برای یک برنامه‌نویس، تفاوت بین یک مدل اسباب‌بازی و یک محصول واقعی، در نحوه برخورد سیستم با خطاها، امنیت و هم‌زمانی است. این یک تمرین ساده از نوع «Hello World» نیست؛ بلکه موضوع معماری پروتکل و تصمیمات طراحی آگاهانه است که در کدهای پایتون محیط تولید پیاده‌سازی می‌شوند.

معماری هسته: بهره‌وری M+N

به نقل از گزارش dev.to در ۳ جولای ۲۰۲۶، پروتکل MCP یک مشکل مقیاس‌پذیری ترکیبی را حل می‌کند. در ساختار سنتی، اگر M اپلیکیشن مدل زبانی بزرگ (LLM) — مثل Claude Desktop، Cursor، VS Code یا ChatGPT — بخواهند به N سیستم خارجی مثل یک دیتابیس، GitHub، یک API داخلی یا WordPress دسترسی داشته باشند، نیاز به M×N ادغام اختصاصی است. در این حالت، هر جفت از این ارتباطات به فرمت، سیستم احراز هویت و بار نگهداری جداگانه‌ای نیاز دارد.

MCP این پیچیدگی را به M+N کاهش داد. شما یک سرور را یک بار می‌نویسید و هر کلاینت سازگار می‌تواند بدون حتی یک خط کد اضافی در سمت خود، قابلیت‌های آن را کشف و استفاده کند. از نظر مکانیکی، MCP بر پایه JSON-RPC 2.0 بنا شده و سه نقش اصلی را تعریف می‌کند:

• میزبان (Host): اپلیکیشن LLM که هماهنگ‌کننده کل عملیات است.
• کلاینت (Client): توسط میزبان ایجاد می‌شود و برای هر سرور، یک کلاینت مجزا وجود دارد.
• سرور (Server): موجودیتی که زمینه (Context) و قابلیت‌های واقعی را فراهم می‌کند.

این ساختار دقیقاً مشابه پروتکل سرور زبان (LSP) است و استاندارد می‌کند که داده‌ها و ابزارها چگونه به اکوسیستم AI متصل شوند. طبق اعلام توسعه‌دهندگان، MCP صرفاً یک «فراخوانی تابع» (Function Calling) نیست. در حالی که فراخوانی تابع یک مکانیسم تک-فروشنده است که در آن توابع برای یک مدل خاص در کد تعریف می‌شوند، MCP یک پروتکل انتقال و لایه مذاکره است. در اینجا، سرور قابلیت‌های خود را اعلام می‌کند، کلاینت آن‌ها را در زمان اجرا کشف می‌کند و نسخه‌ها در ابتدای اتصال согласо می‌شوند، که باعث می‌شود سرور در هر میزبان قابل استفاده باشد.

تفکیک ابزارها، منابع و پرامپت‌ها

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

• ابزارها (Tools): اکشن‌های قابل اجرا که دارای منطق و اعتبارسنجی هستند. این‌ها توسط مدل کنترل می‌شوند (مدل زمانی که نیاز داشته باشد آن‌ها را فراخوانی می‌کند) تا عملیات اثرگذار یا منطق‌های پیچیده را اجرا کنند. مثال: «ایجاد یک پست با عنوان X و وضعیت Y».
• منابع (Resources): داده‌های فقط-خواندنی که تحت یک الگوی URI هستند. این‌ها توسط اپلیکیشن یا میزبان کنترل شده و زمینه استاتیک یا نیمه-استاتیک فراهم می‌کنند. مثال: «محتویات سند Z».
• پرامپت‌ها (Prompts): قالب‌های بازیافتی که کاربر به‌صورت آگاهانه برای دستورالعمل‌های تکرارپذیر و ساختاریافته انتخاب می‌کند. این‌ها یک سناریوی آماده و پارامتری شده را به کاربر تحویل می‌دهند.

در عمل، بیشتر سرورها به شدت بر ابزارها متکی هستند، در حالی که منابع و پرامپت‌ها را برای بهینه‌سازی زمینه (Context Optimization) به کار می‌برند.

انتقال به مدل بدون وضعیت (Stateless)

بر اساس بازنگری پروتکل در ۲۸ جولای ۲۰۲۶ (که در حال حاضر یک نسخه کاندیدای انتشار یا RC است و با شناسه SEP-2567 شناخته می‌شود)، نشست‌های (Session) سطح پروتکل حذف شده‌اند. حذف هدر Mcp-Session-Id به این معناست که نسخه پروتکل، اطلاعات کلاینت و قابلیت‌ها اکنون در فیلد _meta هر درخواست ارسال می‌شوند. همچنین متد جدید server/discover به کلاینت اجازه می‌دهد قابلیت‌های سرور را در صورت نیاز (On-demand) دریافت کند.

این تغییر نیاز به مسیریابی چسبنده (Sticky Routing) و ذخیره‌سازهای مشترک نشست در استقرارهای افقی را از بین می‌برد. اگر سروری به وضعیت (State) نیاز دارد، توسعه‌دهنده باید اکنون از دستگیره‌های صریح استفاده کند؛ مثلاً یک basket_id که توسط یک ابزار ایجاد شده و در فراخوانی‌های بعدی به عنوان یک آرگومان معمولی بازگردانده می‌شود. این طراحی اجازه می‌دهد هر درخواست روی هر نمونه از سرور بنشیند و هزینه مقیاس‌دهی را به‌شدت کاهش دهد. طراحی برای انتقال بدون وضعیت از همان ابتدا، ارزان‌ترین مسیر برای رسیدن به مقیاس است.

پیاده‌سازی با FastMCP

SDK رسمی پایتون شامل FastMCP است؛ یک چارچوب سطح بالا که تولید طرح‌واره ورودی را از طریق docstring‌ها خودکار کرده و از Pydantic برای اعتبارسنجی استفاده می‌کند. یک پیاده‌سازی حرفه‌ای با استراتژی‌های زیر از یک کد ساده تفکیک می‌شود:

• اعتبارسنجی سخت‌گیرانه: استفاده از مدل Pydantic با تنظیم extra="forbid" تضمین می‌کند که سرور فیلدهای ناشناخته را به‌جای نادیده گرفتن، رد کند. این مورد با str_strip_whitespace=True و محدودیت‌های خاص فیلد (مثلاً min_length=1 و max_length=100) ترکیب می‌شود.
• ورودی/خروجی نامتقارن (Async I/O): استفاده از async def و httpx.AsyncClient (با تعریف تایم‌اوت‌های مشخص، مثلاً ۱۰ ثانیه) تضمین می‌کند که یک پروسه بتواند تعداد زیادی فراخوانی هم‌زمان را بدون مسدود کردن حلقه رویداد (Event Loop) مدیریت کند. این مقیاس‌دهی I/O مشابه نحوه عملکرد epoll و io_uring در سطح سیستم است.
• توضیحات صادقانه: استفاده از دکوراتورهای خاص برای اطلاع‌رسانی به میزبان درباره ماهیت ابزار:
  • readOnlyHint: ابزار وضعیتی را تغییر نمی‌دهد (مثلاً دریافت پیش‌بینی هوا).
  • destructiveHint: عملیات غیرقابل بازگشت است (مثلاً حذف یک منبع).
  • idempotentHint: تکرار فراخوانی تغییری در نتیجه ایجاد نمی‌کند (مثلاً تنظیم یک مقدار روی X).
  • openWorldHint: ابزار به سیستم‌های خارجی متصل می‌شود (مثلاً کوئری گرفتن از یک API آب‌وهوا).

مدیریت خطا به عنوان راهنمای مدل

در سرورهای MCP، پیام‌های خطا لاگ‌هایی برای انسان نیستند، بلکه دستورالعمل‌های بازیابی برای مدل‌اند. یک خطای کلی مثل «Error 404» برای یک LLM بی‌فایده است. در عوض، سرور باید بازخوردی عملی (Actionable) ارائه دهد. توسعه‌دهندگان با استفاده از یک تابع کمکی مثل _handle_error می‌توانند کدهای وضعیت HTTP را به راهنمایی تبدیل کنند:

• ۴۰۴: «خطا: شهر یافت نشد. لطفاً املای نام را بررسی کنید.»
• ۴۲۹: «خطا: حد نرخ درخواست (Rate Limit) exceeded شد. پیش از تلاش مجدد منتظر بمانید.»
• Timeout: «خطا: درخواست به دلیل زمان‌بر بودن متوقف شد. لطفاً دوباره تلاش کنید.»

این دقت به مدل می‌گوید دقیقاً چگونه تلاش بعدی خود را اصلاح کند، مسیر رسیدن به نتیجه موفق را کوتاه می‌کند و مانع از گیر افتادن عامل در یک حلقه تکراری (Infinite Loop) می‌شود.

امنیت و مدل اعتماد

امنیت در MCP بر این فرض استوار است که توصیفات ابزارها غیرقابل اعتماد هستند. مشخصات پروتکل صراحتاً ذکر می‌کند که ابزارها نمایانگر اجرای کدهای دلخواه (Arbitrary Code Execution) هستند و باید با احتیاط برخورد شوند. از آنجایی که توصیفات و حاشیه‌نویسی‌ها می‌توانند برای جاسازی دستورات مخفی استفاده شوند، توسعه‌دهندگان باید در برابر تزریق پرامپت (Prompt Injection) از طریق خروجی ابزار محافظت کنند.

برای کاهش این ریسک‌ها، سرورهای محیط تولید باید موارد زیر را رعایت کنند:
۱. برون‌سپاری اسرار: کلیدها (مثل WEATHER_API_KEY) را در متغیرهای محیطی از طریق os.environ نگه دارند و هرگز آن‌ها را در کد یا توصیفات قرار ندهند.
۲. انتقال امن: استفاده از OAuth 2.1 / OIDC برای انتقالات راه دور. بازنگری ۲۸ جولای ۲۰۲۶ مجوزها را با این استانداردها همسو کرد و اکستنشن Enterprise-Managed Authorization اکنون پایدار است.
۳. حفظ قرارداد: دروغ گفتن درباره readOnlyHint در ابزاری که داده را حذف می‌کند، نقض قرارداد امنیتی است. اپلیکیشن میزبان جریان‌های رضایت کاربر (User-consent flows) را بر اساس این سیگنال‌ها می‌سازد و حاشیه‌نویسی‌های نادرست، این مدل اعتماد را می‌شکند.

مقیاس‌دهی و هم‌زمانی

انتخاب نوع انتقال (Transport) اولین تصمیم معماری بزرگ است. این انتخاب به هدف استقرار بستگی دارد:

• stdio: ایده‌آل برای ابزارهای CLI محلی و یکپارچگی‌های تک-ماشینه است و از یک پروسه واحد استفاده می‌کند.
• Streamable HTTP: برای سرورهای تولیدی، SaaS و استقرارهای راه دور روی HTTPS ضروری است تا کلاینت‌های هم‌زمان متعددی را پشتیبانی کند.

به دلیل اینکه تمام عملیات I/O به‌صورت نامتقارن (Asynchronous) مدیریت می‌شوند، سرور می‌تواند تعداد زیادی کلاینت هم‌زمان را به‌طور بهینه مدیریت کند. با حذف مسیریابی مبتنی بر نشست در آخرین مشخصات، مقیاس‌دهی افقی اکنون صرفاً شامل قرار دادن نمونه‌های بیشتر پشت یک Load Balancer استاندارد است. تغییر محیط اجرا از محلی به راه دور تنها با تغییر دستور اجرا ممکن است: mcp.run(transport="streamable_http", port=8000).

این نظم معماری، سرور AI را از یک اسکریپت شکننده به یک زیرساخت تاب‌آور تبدیل می‌کند. با اولویت دادن به مدل بدون وضعیت، اعتبارسنجی صریح و سیگنال‌دهی صادقانه، توسعه‌دهندگان تضمین می‌کنند که ابزارهایشان از تکامل سریع پروتکل جان سالم به در ببرند. امروز برای آینده بدون-نشست (Sessionless) طراحی کنید تا سرورتان بدون نیاز به بازنویسی کامل، از این گذار عبور کند.

گام بعدی شما

• اگر سرور MCP محلی دارید، آن را با استفاده از transport="streamable_http" به مدل راه دور منتقل کنید تا مقیاس‌پذیری را آزمایش کنید.
• تمامی توابع ابزار خود را با مدل‌های Pydantic و پارامتر extra="forbid" بازنویسی کنید تا از ورودی‌های غیرمنتظره مدل جلوگیری شود.
• پیام‌های خطای generic را با راهنماهای متنی جایگزین کنید تا نرخ موفقیت عامل در تلاش‌های دوم افزایش یابد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.