MCP چیست؟ پروتکل اتصال مدل به داده و ابزار

مسئله‌ای که با هر ادغام جدید بزرگ‌تر می‌شود

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

این همان مسئله‌ی N×M است: N برنامه‌ی مبتنی بر هوش مصنوعی، M منبع داده و ابزار، و در بدترین حالت N×M کد اتصال. MCP — سرنام Model Context Protocol — دقیقاً برای شکستن این ضرب ساخته شده. اگر هر منبع داده یک‌بار خودش را با یک پروتکل مشترک عرضه کند و هر برنامه یک‌بار همان پروتکل را بفهمد، N×M تبدیل به N+M می‌شود.

MCP یک پروتکل باز است که Anthropic منتشر کرده و مشخصات و پیاده‌سازی‌های مرجعش متن‌باز است. ایده‌اش تازه نیست؛ همان کاری است که LSP برای ویرایشگرها و زبان‌های برنامه‌نویسی کرد.

پروتکل دقیقاً چه چیزی را استاندارد می‌کند

MCP سه چیز را قالب‌بندی می‌کند:

• کشف قابلیت‌ها. برنامه از سرور می‌پرسد «چه چیزی داری؟» و فهرست ساخت‌یافته‌ای از ابزارها همراه با نام، توضیح و schema ورودی دریافت می‌کند.
• فراخوانی. برنامه ابزاری را با ورودی مشخص صدا می‌زند و نتیجه‌ی ساخت‌یافته می‌گیرد.
• قالب پیام و انتقال. پیام‌ها بر پایه‌ی JSON-RPC رد و بدل می‌شوند و می‌توانند روی ورودی/خروجی استاندارد یک فرایند محلی یا روی HTTP جابه‌جا شوند.

علاوه بر ابزار — که پرکاربردترین بخش است — پروتکل مفاهیم دیگری هم دارد، از جمله resource برای عرضه‌ی محتوای خواندنی مثل فایل و رکورد، و prompt برای الگوهای آماده‌ای که برنامه می‌تواند به کاربر پیشنهاد دهد. اگر تازه شروع کرده‌اید، با ابزارها شروع کنید؛ بقیه بعداً معنا پیدا می‌کند.

server و client

دو نقش وجود دارد و جدا نگه داشتنشان کل ماجرا را ساده می‌کند.

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

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

جریان کار در عمل چیزی شبیه این است:

1. میزبان بالا می‌آید و به سرورهای پیکربندی‌شده وصل می‌شود.
2. از هر سرور فهرست ابزارها را می‌گیرد.
3. این فهرست را به‌شکل تعریف ابزار به مدل می‌دهد.
4. مدل تصمیم می‌گیرد ابزاری صدا زده شود.
5. کلاینت فراخوانی را به سرور می‌فرستد، نتیجه را می‌گیرد و به مدل برمی‌گرداند.
6. حلقه‌ی ایجنت ادامه پیدا می‌کند.

گام‌های ۴ و ۵ دقیقاً همان function calling همیشگی است. MCP آن را عوض نمی‌کند؛ فقط استاندارد می‌کند که تعریف ابزار از کجا می‌آید و فراخوانی به کجا می‌رود.

MCP چه چیزی نیست

اینجا بیشترین سردرگمی وجود دارد، پس صریح باشیم:

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

کی به سراغش بروید و کی نه

ارزشش را دارد وقتی:

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

احتمالاً لازم نیست وقتی:

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

قاعده‌ی ساده: MCP وقتی سود می‌دهد که همان ابزار قرار باشد بیش از یک بار مصرف شود. برای مصرف یک‌باره، هزینه‌ی لایه‌ی اضافه بیشتر از سودش است.

نکته‌های عملی برای وقتی که به‌کارش می‌گیرید

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

جمع‌بندی

MCP یک پروتکل مشترک برای معرفی و فراخوانی ابزار و داده است تا هر ایجنت مجبور نباشد اتصال اختصاصی خودش را برای هر منبع بنویسد. سرور قابلیت عرضه می‌کند، کلاینت آن را به مدل می‌رساند، و مسئله‌ی N×M به N+M کوچک می‌شود. اما پروتکل، ایجنت شما را نمی‌سازد و امنیتش را تضمین نمی‌کند؛ فقط لایه‌ی اتصال را از یک کار تکراری به یک قرارداد تبدیل می‌کند.