نکات کلیدی
-
APIها و سرورهای MCP از نظر ویژگیها و هدفها مشابهاند، اما APIها منبعمحور هستند و سرورهای MCP وظیفهمحور. بنابراین سرورهای MCP به یک رویکرد راهبردی نیاز دارند، نه تبدیل ۱ به ۱.
-
تبدیل APIها به سرورهای MCP نیازمند هماهنگسازی چندین فراخوانی API در قالب «ابزارهایی» منسجم است که مدلهای زبانی بزرگ (LLM) بتوانند آنها را بفهمند و اجرا کنند.
-
پیادهسازی موفق MCP از تعریف مورد استفاده و منطق کسبوکار شروع میشود، سپس منابع API طوری پیادهسازی میشوند که از وظایف مشخص پشتیبانی کنند.
-
رویکردهای امنیتی در APIها و سرورهای MCP متفاوت است: سرورهای MCP برای تعاملات LLM از OAuth 2.1 استفاده میکنند و پس از آن، فراخوانیهای بعدی به APIها میتواند با کلید API، OAuth 2.0، احراز هویت پایه (Basic Auth) و… انجام شود.
از زمان معرفی MCP توسط Anthropic در نوامبر ۲۰۲۴، پذیرش MCP بهشدت رشد کرده است؛ هم توسط فروشندگانی که از این پروتکل پشتیبانی میکنند و هم توسط مشتریانی که آن را پیادهسازی میکنند. هدف اصلی MCP این است که توسط مدلهای زبانی بزرگ (LLM) برای بهتر پاسخدادن به پرامپتها استفاده شود، و این پروتکل همان «رابطی» است که LLMها از آن برای تعامل با سامانهها و برنامههای بکاند جهت اجرای اقدامها استفاده میکنند. مورد استفادهاش شبیه استفاده از APIها توسط برنامههای کلاینت است. همین شباهت باعث میشود توسعهدهندگان سریع به این نتیجه برسند که میتوانند از APIهای موجود، یک سرور MCP بسازند و همان قابلیتها را برای LLMها «نمایان» کنند.
اما در بنیاد ماجرا، این روش، راه درست ساخت رابطهای MCP نیست؛ چون بین LLMها و برنامههای سنتی تفاوتهای اساسی وجود دارد. رابطه بیشتر شبیه این است که «قطعات سازنده» API را در یک سرور MCP مستقر کنید، نه اینکه آن را تبدیل کنید.
بیایید تفاوتها و شباهتهای اصلی سرورهای MCP و APIها را بررسی کنیم و چند بهترین روش هم برای ساخت سرورهای MCP از APIهای موجود ارائه دهیم.
APIها در برابر سرورهای MCP: تفاوت چیست؟
هم APIها و هم سرورهای MCP «رابط»هایی هستند که به برنامههای کلاینت اجازه میدهند از طریق یک پروتکل استاندارد با برنامههای سرور تعامل کنند. این پروتکل مستقل از فناوری و پیادهسازی کلاینت و سرور است.
اما با اینکه APIها و سرورهای MCP ویژگیهای مشترک زیادی دارند، چند تفاوت بنیادی وجود دارد که باید در نظر گرفت. این دو از «لایههای انتزاع» متفاوتی استفاده میکنند. تفاوتها را در جدول زیر برجسته میکنیم.
جدول مقایسه APIها و سرورهای MCP (همان جدول مقاله)
| APIها | سرورهای MCP |
|---|---|
| APIها منبعمحور هستند و روشهای API برای دستکاری منابع به کار میروند. مثال: روش API GET /invoice/invoiceid برای دریافت جزئیات منبع «فاکتور». |
سرورهای MCP وظیفهمحور هستند و «ابزارها» برای اجرای یک وظیفه مشخص استفاده میشوند. مثال: ابزار read_invoice_details برای دریافت جزئیات یک فاکتور.سرورهای MCP همچنین «منابع» دارند برای ارائه داده و «پرامپتها» دارند برای ارائه قالبهای پرامپت. |
| تعامل بین یک برنامه کلاینت و یک API معمولاً درخواست/پاسخ است. کلاینت درخواست میفرستد و API پاسخ میدهد. | تعامل بین یک کلاینت MCP و یک سرور MCP پیچیدهتر است: – مرحله آغازین برای مذاکره درباره نسخه، قابلیتها و پیادهسازی – مرحله عملیات که در آن کلاینت یک درخواست کسبوکاری میفرستد و سرور پاسخ میدهد – مرحله خاموشسازی برای متوقفکردن تعامل |
فراخوانی API میتواند با همه روشهای HTTP انجام شود: GET، POST، PUT، PATCH، DELETE. یک GET دادههای یک منبع را بازیابی میکند و یک POST یک نمونه از منبع را ایجاد میکند. |
فراخوانی سرور MCP همیشه از طریق HTTP POST است. برای گرفتن داده، مثلاً getResourceInfo را روی HTTP POST صدا میزنید. برای ایجاد منبع، مثلاً createNewResource را روی HTTP POST صدا میزنید. |
| یک API میتواند دهها منبع داشته باشد و هر منبع با روشهای مختلف API دستکاری شود. | برای یک سرور MCP توصیه میشود تعداد ابزارها، پرامپتها و منابع محدود باشد و حداکثر ۵۰ تا باشد. |
| APIها توسط برنامههای کلاینت استفاده میشوند؛ این برنامهها منطق کسبوکار از پیش تعریفشدهای دارند تا APIها را صدا بزنند. منطق کسبوکار میتواند چند فراخوانی API را به هم وصل کند تا یک مورد استفاده تکمیل شود. مثال: برای ساخت یک رکورد مشتری جدید، ۵ فراخوانی مختلف API باید با ترتیب مشخص انجام شود. |
ابزارها توسط LLMها استفاده میشوند و چون LLMها احتمالاتی هستند، نمیشود پیشبینی کرد LLM برای رسیدن به هدفش از چه ابزارهایی استفاده میکند. LLM همچنین برای چسباندن چند اقدام ریزدانه به هم جهت تکمیل یک مورد استفاده، مناسب نیست. مثال: اگر ساخت یک مشتری جدید نیازمند ۵ فراخوانی API با ترتیب مشخص باشد، LLM بهاحتمال زیاد نمیتواند خودش این را درست کشف کند. |
| مستندسازی مهم است تا توسعهدهندگانی که از API استفاده میکنند بفهمند APIها چه میکنند و چطور در برنامههایشان استفاده شوند. مستندات توسط خودِ برنامهای که API را صدا میزند استفاده نمیشود. | مستندسازی سرور MCP برای برنامهای که از آن استفاده میکند حیاتی است. LLM از «توضیح ابزار» استفاده میکند تا بفهمد ابزار چه کاری انجام میدهد و چه زمانی باید از آن استفاده کند. |
| APIها میتوانند با مشخصات استاندارد مثل OpenAPI، RAML و API Blueprint توصیف شوند. | در حال حاضر، مشخصات رسمیای برای توصیف یک سرور MCP وجود ندارد و این کار ارائه یک فایل واحد برای توصیف کل سرور MCP را به شکل استاندارد دشوارتر میکند. |
| API یک مفهوم بسیار بالغ است، پس نباید انتظار تغییرات بزرگ و مهم زیادی در فناوری و مشخصات آن داشته باشیم. | MCP یک استاندارد نسبتاً جدید است و نسخه رسمی اولیهاش از نوامبر ۲۰۲۴ در دسترس بوده است. تغییرات بزرگ، از جمله تغییرات ناسازگار (شکننده)، همین حالا هم در پروتکل معرفی شدهاند. |
| سازوکارهای متعدد احراز هویت و مجوزدهی وجود دارد، مثل کلید API، OAuth، mTLS، احراز هویت پایه (Basic Auth) و… | هرچند از نظر فنی میتوان از سازوکارهای مختلف استفاده کرد، خودِ پروتکل بیان میکند که OAuth 2.1 در حال حاضر بهترین پروتکل برای استفاده است. |
چطور یک API را به یک سرور MCP تبدیل کنیم
با درک بهتر شباهتها و تفاوتهای سرورهای MCP و APIها، میبینید که ماجرا به سادگیِ تبدیل مستقیم ۱ به ۱ از API به سرور MCP نیست.
مسئله این نیست که خودِ API را «تبدیل» کنید، بلکه این است که آن را وارد یک اکوسیستم گستردهتر هوش مصنوعی کنید: MCP درباره «یکپارچهسازی» است؛ یک LLM را به سرویسهای دیگر، عاملها یا گردشکارها وصل میکند. پس API صرفاً به سرور MCP تبدیل نمیشود؛ بلکه قابلیتهای API از طریق یک سرور MCP در دسترس قرار میگیرد.
برای نشاندادن بهترین روش، از یک مثال کسبوکاری استفاده میکنیم.
گام ۱: مورد استفاده MCP را تعریف کنید
اولین گام این است که مورد استفادهای را که میخواهید سرور MCP پوشش دهد تعریف کنید. مثلاً ممکن است یک سرور MCP بخواهید که یک LLM بتواند از آن برای مدیریت خرید لپتاپهای جدید استفاده کند تا کارمندان شرکت با یک چتبات، خودکفاتر شوند.
وقتی سرور MCP را تعریف کردید، باید تصمیم بگیرید سرور MCP چه «ابزارهایی» باید داشته باشد. یک ابزار باید یک «وظیفه» باشد که LLM بتواند آن را بفهمد و باید یک اقدام واحد باشد. برای این مورد استفاده، باید ۳ ابزار ساخته شود که ۳ حالتِ فرایند سفارش لپتاپ را پوشش میدهند:
-
check_laptop_offering -
order_laptop -
check_status_of_order
گام ۲: منطق کسبوکار سرورهای MCP را بسازید
حالا که مشخص کردید چه ابزارهایی میخواهید پیادهسازی کنید، میتوانید منطق کسبوکار این ابزارها را بسازید. این ابزارها از API تدارکات فناوری اطلاعات (IT Procurement API) و API موجودی فناوری اطلاعات (IT Inventory API) استفاده خواهند کرد.
چون APIها منبعمحور هستند و سرورهای MCP وظیفهمحور، معمولاً نمیتوان یک ابزار را مستقیم از یک روش API ساخت. برای ابزارهای مثال ما، لازم است برای انجام وظیفهای که در توضیح ابزار آمده، چند روش API مختلف را فراخوانی کنیم.
check_laptop_offering
-
گرفتن فهرست مدلهای موجود:
GET /it/procurement/laptop -
گرفتن موجودی هر مدل:
GET /it/inventory/laptop/model
order_laptop
-
بررسی اعتبار لپتاپ فعلی:
GET /it/procurement/laptop/[id]/validity -
بررسی اینکه لپتاپ جدید با چیزی که کارمند اجازه سفارش آن را دارد همخوان است:
GET /it/procurement/laptop/order/[userid] -
سفارش لپتاپ:
POST /it/procurement/laptop
check_status_of_order
-
بررسی وضعیت سفارش:
GET /it/procurement/laptop/order/[id]
همانطور که مشخص است، برای انجام وظیفه یکی از ابزارهای MCP باید چند روش API را با منابع مختلف فراخوانی کنیم. این نشان میدهد که نمیتوان صرفاً یک API را به یک سرور MCP تبدیل کرد.
گام ۳: احراز هویت و مجوزدهی لازم را اضافه کنید
APIهای مختلف میتوانند با سازوکارهای احراز هویت متفاوت محافظت شوند. یک سرور MCP باید با OAuth 2.1 محافظت شود، و سرور MCP باید بتواند API را با سازوکارهای احراز هویتی که خودِ API تعریف کرده است فراخوانی کند.
این یعنی درخواست ورودی از LLM به سرور MCP با OAuth 2.1 احراز هویت میشود، و فراخوانیهای خروجی بعدی به روشهای مختلف API با سازوکارهای دیگر مثل کلید API، OAuth 2.0، احراز هویت پایه (Basic Auth) و… احراز هویت خواهند شد.
این پست نشان داد که با وجود اینکه سرورهای MCP و APIها هدفی مشابه دارند (ارائه یک رابط برای تعامل برنامههای کلاینت با برنامههای بکاند)، تفاوتهای بنیادی میان آنها وجود دارد که معمولاً تبدیل ۱ به ۱ یک API به یک سرور MCP را ناممکن میکند. ویژگیهای MCP ممکن است دورِ یک API «پیچیده» شوند، اما آینه دقیق آن نیستند.
به همین دلیل، مهم است فرآیندی را دنبال کنید که از تعریف مورد استفاده سرور MCP شروع میشود و سپس APIهای لازم برای پشتیبانی از آن مورد استفاده را تعریف و پیادهسازی میکند.
