پرش به محتوای اصلی
پرش به محتوای مقاله

معماری سرور MCP: تفاوت‌های حیاتی میان استقرار محلی و ابری

·۲۹ مرداد ۱۴۰۵۴ دقیقه مطالعه
راهنما
سرورهای محلی در مقابل راه‌دور MCP: کدام را واقعاً می‌خواهید
سرورهای محلی در مقابل راه‌دور MCP: کدام را واقعاً می‌خواهید
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

شفاف‌سازی تفاوت عملیاتی بین سرورهای stdio و HTTP در MCP و معرفی فایل `.mcpb` به عنوان مرز تعیین‌کننده برای پذیرش افزونه‌ها در اکوسیستم Anthropic.

تصور کنید ساعت‌ها زمان توسعه را صرف ساخت ابزاری کنید که در نهایت به دلیل اشتباه در انتخاب معماری سرور، توسط سیستم‌های پذیرش رد شود. هزینه بالای انتخاب معماری اشتباه برای پروتکل زمینه مدل (Model Context Protocol یا MCP) می‌تواند شامل اتلاف زمان توسعه و ریسک رد شدن درخواست‌های ثبت اثر باشد. در دنیای MCP، تمام این ریسک به یک پرسش ساده و بنیادین ختم می‌شود: کد توسط چه کسی اجرا می‌شود و داده‌ها دقیقاً کجا قرار دارند؟

برای توسعه‌دهندگانی که در ۲۰ آگوست ۲۰۲۶ در حال ساخت افزونه‌های هوش مصنوعی هستند، اکوسیستم به دو شکل و مسیر کاملاً مجزا تقسیم شده است. سرورهای محلی به عنوان فرآیندهایی روی ماشین کاربر اجرا می‌شوند، اما سرورهای راه دور به صورت سرویس‌های میزبانی‌شده (Hosted) عمل می‌کنند. این تمایز، هر چیزی از نحوه مدیریت کلیدهای امنیتی و اسرار (Secrets) گرفته تا استراتژی استقرار و به‌روزرسانی را تعیین می‌کند.

سرورهای محلی در مقابل ریموت MCP: کدام را واقعاً می‌خواهید

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

قاعده کلی این است: اگر داده‌ها روی زیرساخت شما قرار دارند، سرور باید راه دور باشد. اگر داده‌ها روی ماشین کاربر هستند، سرور حتماً باید محلی باشد. انتخاب یک سرور محلی برای میانجی‌گری (Proxy) یک API راه دور، صرفاً ایجاد هزینه اضافی (Overhead) است؛ زیرا در نهایت شما بدون هیچ سودی، مجبور می‌شوید هم‌زمان یک پوشش (Wrapper) محلی و یک نقطه اتصال (Endpoint) راه دور را نگهداری کنید.

سرورهای محلی (stdio)
سرورهای محلی در واقع بسته‌های نرم‌افزاری هستند که کاربر آن‌ها را نصب می‌کند. کلاینت‌هایی مانند Claude Desktop یا Cursor، سرور را به عنوان یک پروسه ایجاد (Spawn) کرده و از طریق ورودی/خروجی استاندارد (stdin/stdout) با آن ارتباط می‌گیرند. این تفاوت در لایه انتقال می‌تواند منجر به چالشات فنی شود، همان‌طور که در بررسی تفاوت‌های اتصالات HTTP و stdio مشاهده شد که این شکاف‌ها عامل بسیاری از خطاهای شناسناپذیر هستند.

  • دسترسی: این سرورها دسترسی مستقیم دارند و می‌توانند سیستم فایل کاربر را بخوانند، به localhost متصل شوند یا با یک دیمون Docker محلی صحبت کنند.
  • امنیت و اسرار: اعتبارنامه‌ها و کلیدها در پروفایل شل یا فایل‌های تنظیمات شخصی کاربر ذخیره می‌شوند؛ بنابراین توسعه‌دهنده هرگز به این اطلاعات دسترسی ندارد و آن‌ها را نمی‌بیند.
  • به‌روزرسانی: کاربران هر نسخه‌ای را که نصب کرده‌اند اجرا می‌کنند و ممکن است برای همیشه از همان نسخه استفاده کنند، که این موضوع منجر به مشکل «تفاوت نسخه‌ها» (Version-skew) می‌شود.
  • خطا: در این مدل، کرش کردن یا توقف سرور فقط یک ماشین واحد را تحت تأثیر قرار می‌دهد و تأثیری بر سایر کاربران ندارد.

سرورهای راه دور (Streamable HTTP)
سرورهای راه دور سرویس‌های میزبانی‌شده‌ای هستند که کلاینت‌ها از طریق یک URL و با استفاده از توکنی در هدر Authorization به آن‌ها متصل می‌شوند. در این حالت، هیچ نرم‌افزاری به صورت محلی روی سیستم کاربر نصب نمی‌شود.

  • دسترسی: این سرورها نمی‌توانند سخت‌افزار محلی کاربر را ببینند و اساساً نباید چنین تلاشی برای دسترسی به محیط محلی کاربر داشته باشند.
  • امنیت و اسرار: توسعه‌دهنده مالک کامل چرخه حیات اعتبارنامه‌ها است؛ این شامل صدور توکن‌ها، تعیین محدوده دسترسی (Scoping)، چرخش (Rotation) و ابطال (Revocation) آن‌ها می‌شود. در این راستا، انتخاب ابزار مناسب برای مدیریت داده‌ها حیاتی است؛ برای مثال مقایسه DBHub و Bytebase نشان می‌دهد که هر ابزار سطح متفاوتی از امنیت را برای عامل‌های هوش مصنوعی فراهم می‌کند.
  • به‌روزرسانی: استقرار (Deployment) در این مدل فوری است؛ به محض اینکه شما نسخه جدید را مستقر کنید، تمام کاربران بلافاصله از نسخه جدید استفاده می‌کنند.
  • خطا: در اینجا، کرش کردن سرور منجر به یک قطعی سراسری (Global Outage) برای تمام کلاینت‌های متصل می‌شود.

سیگنال پذیرش
به نقل از گزارش dev.to، واضح‌ترین نشانه برای اینکه بدانید کدام مسیر را باید انتخاب کنید، فرم‌های ثبت اثر است. شرکت Anthropic دایرکتوری سرورهای MCP را با دو فرم مجزا مدیریت می‌کند. فرم مربوط به سرورهای محلی بر محور «افزونه‌های دسکتاپ» طراحی شده و الزامات سخت‌گیرانه خاصی دارد:

  • کد باید به صورت عمومی در GitHub در دسترس باشد.
  • باید دارای لایسنس MIT باشد.
  • باید با Node.js ساخته شده باشد.
  • داشتن یک فایل manifest.json معتبر که فیلد نویسنده (Author) در آن به یک پروفایل گیت‌هاب اشاره کند.
  • آپلود یک فایل .mcpb به عنوان یک پیش‌نیاز اجباری.

الزام آخر، همان «نشانه» یا Tell اصلی است. فایل .mcpb در واقع یک افزونه محلی بسته‌بندی شده است که Claude Desktop آن را نصب و اجرا می‌کند. اگر سرور شما از نوع راه دور باشد، اصلاً هیچ بسته‌ای برای تولید وجود ندارد. نکته اینجاست که لینک فرم راه دور معمولاً تنها در یک خط کوچک در بالای فرم محلی قرار دارد، به همین دلیل بسیاری از توسعه‌دهندگان هنگام مطالعه سریع، آن را نادیده می‌گیرند.

احراز هویت و امنیت در سرورهای راه دور
برای کسانی که مسیر راه دور را انتخاب می‌کنند، امنیت به یک بار مهندسی سنگین تبدیل می‌شود زیرا مالکیت و مسئولیت اعتبارنامه‌ها کاملاً با توسعه‌دهنده است. در این حالت، چندین رویه از حالت اختیاری به اجباری تبدیل می‌شوند:

  • محدودسازی دامنه (Narrow Scoping): توکن‌ها باید طوری طراحی شوند که فقط بتوانند زمینه (Context) مربوط به یک وظیفه واحد را بخوانند. این کار باعث می‌شود در صورت نشت یک توکن، خسارت وارده در مقایسه با توکنی که دسترسی کامل به حساب کاربری دارد، بسیار محدودتر باشد.
  • انقضای پیش‌فرض: انقضا (Expiry) باید حالت پیش‌فرض باشد، نه ابطال (Revocation) دستی. ابطال به حافظه و دقت انسان متکی است، اما انقضای خودکار تضمین می‌کند که غفلت یا فراموشی توسعه‌دهنده بی‌خطر باشد.
  • متغیرهای محیطی: هرگز نباید اجازه دهید یک توکن در فایلی که Commit شده قرار گیرد. باید در تنظیمات به یک متغیر محیطی ارجاع دهید و مقدار آن را از پروفایل شل اکسپورت کنید. حذف یک خط از یک برنچ راه دور، مقدار آن را از تاریخچه (History) گیت پاک نمی‌کند؛ در چنین شرایطی، تنها راه حل واقعی، چرخش (Rotation) توکن است.

این شکاف معماری به این معناست که ساخت یک پوشش محلی برای یک API راه دور، صرفاً اتلاف وقت و ایجاد هزینه اضافی است. برای مثال، سرویس Wagglet از سرور راه دور استفاده می‌کند زیرا رابطی برای یک تخته وظایف مشترک است که در آن داده‌ها متعلق به سرویس هستند، نه کاربر. در این زمینه، مقایسه استقرار در Appwrite و Vercel نشان می‌دهد که چگونه کنترل بیشتر روی بک‌اند می‌تواند در مقابل سرعت استقرار، برتری‌های استراتژیک ایجاد کند.

گام بعدی شما

  • پروژه‌های فعلی MCP خود را بازبینی کنید تا مطمئن شوید لایه انتقال (Transport Layer) شما با محل ذخیره داده‌هایتان (Data Residency) هم‌خوانی دارد.
  • پیش از نهایی کردن مسیر ساخت و کدنویسی، الزامات ثبت اثر را برای وجود یا عدم نیاز به فایل .mcpb به دقت چک کنید.
  • اگر سرور راه دور دارید، استراتژی انقضای خودکار توکن‌ها را جایگزین ابطال دستی کنید تا امنیت سیستم تضمین شود.

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

چرا این موضوع مهم است؟

این تمایز معماری مستقیماً بر امنیت داده‌ها و سرعت به‌روزرسانی ابزارهای AI اثر می‌گذارد. بر اساس استانداردهای مهندسی نرم‌افزار، انتخاب اشتباه در این لایه منجر به ایجاد حفره‌های امنیتی در دسترسی به فایل‌های محلی کاربر یا هزینه‌های عملیاتی بی‌مورد در زیرساخت ابری می‌شود.

تأثیر برای ایران

برای توسعه‌دهندگان ایرانی، استفاده از سرورهای محلی (Local) به دلیل عدم نیاز به میزبانی ابری و دور زدن محدودیت‌های احتمالی API در لایه انتقال، مسیر سریع‌تر و کم‌هزینه‌تری برای ساخت ابزارهای شخصی‌سازی شده است.

·نگاه ما
تحریریه دات‌هوش

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

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

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