سرور MCP را چطور انتخاب و ارزیابی کنیم

شش سرور MCP روی این ماشین نصب و زنده اندازه‌گیری شدند و جمع فهرست ابزارهایشان پیش از آنکه کاربر یک کلمه بنویسد، ۱۲٬۱۳۰ توکن جا می‌گیرد. گیت‌هاب ۲۶ ابزار دارد، نه ۳۵، و به‌تنهایی ۵٬۹۲۱ توکن؛ اسلک ۸ ابزار و ۱٬۰۶۲ توکن. بیشترین فاصله از جایی می‌آید که انتظارش را ندارید: همان ۹ ابزار حافظه، بدون طرح‌واره‌ی خروجی ۱٬۵۷۶ توکن‌اند و با آن ۳٬۵۱۸. زمان خواندن داده: ۲۵ سپتامبر ۲۰۲۶.

اول روش‌شناسی: چه چیزی را می‌شماریم

پیش از هر عددی باید روشن کرد کلاینت چه چیزی را نگه می‌دارد. کلاینت «تعداد ابزار» را نگه نمی‌دارد؛ یک بلوک متن رندرشده را نگه می‌دارد. آن بلوک از چهار چیز ساخته می‌شود: نام ابزار، توضیحش، طرح‌واره‌ی ورودی، و در بسیاری از کلاینت‌ها طرح‌واره‌ی خروجی. و بیشتر اعداد این حوزه گمراه‌کننده‌اند، چون به این بستگی دارند که چطور رندر کنیم.

من هر ابزار را از سروری گرفتم که روی همین ماشین واقعاً بالا آمده بود، و چهار قالب رندر را روی همان فهرست اجرا کردم. شمارنده، کدگذار o200k_base از کتابخانه‌ی tiktoken نسخه‌ی ۰٫۱۴٫۰ است. نام و نسخه‌ی هر بسته از همان صفحه‌ی بسته‌ی mcp در رجیستری پایتون خوانده شد، نه از راهنمای بسته.

def render(t, verbose):
    d = {"name": t.name, "description": t.description,
         "inputSchema": t.input_schema}
    if verbose:
        d["outputSchema"] = t.output_schema
    return json.dumps(d, ensure_ascii=False, sort_keys=True, indent=2)

# slim = render(t, False), verbose = render(t, True)
# then: sum(len(enc.encode(r)) for t in tools for r in ...)

نتیجه‌ی نخست این جدول: قالب رندر تا ۳۱ درصد اختلاف می‌سازد. همان فهرست گیت‌هاب، ۴٬۴۱۵ توکن به شکل JSON فشرده، ۵٬۹۲۱ توکن به شکل JSON زیبا و ۴٬۲۵۹ توکن به شکل بلوک متنی. پس پرسش «این سرور چند توکن هزینه دارد» بدون گفتن قالب، پرسش بی‌معنایی است. نکته‌ی دوم آن است که خودِ رندر هم قراردادی است، نه سلیقه‌ی کلاینت: نسخه‌ی دوم کتابخانه‌ی کلاینت در راهنمای کلاینت نسخه‌ی دو تعریف می‌کند که کدام بخش از طرح‌واره واقعاً به مدل داده می‌شود.

ستون آخر، یک نکته‌ی روشن دارد: فهرست ابزار بدون توضیح و بدون طرح‌واره عملاً بی‌استفاده است، ۲۰۹ توکن در برابر ۱۲٬۱۳۰. یعنی هزینه‌ی یک سرور تقریباً تماماً در متنی است که خود سرور منتشر می‌کند، نه در نام ابزارها. از این رو نام فیلدها و توضیح هر ابزار، جایی است که نویسنده‌ی سرور بیشترین کنترل را دارد و بیشترین هزینه را هم تولید می‌کند.

آنچه واقعاً تفاوت می‌سازد: طرح‌واره‌ی خروجی

اینجا به گزاره‌ای می‌رسم که با ادعای رایج نقض می‌شود. جایی که بحث می‌شود «گیت‌هاب ابزار زیادی دارد»، اما فهرست واقعی‌اش ۲۶ ابزار است، نه ۳۵. با این حال هزینه‌اش همچنان بلندترین است. علت را اندازه گرفتم: همان فهرست، با و بدون طرح‌واره‌ی خروجی.

این یک معیار عملی می‌سازد که در آغاز قیمت‌گذاری بسیاری از سرورها غایب است: هزینه به‌ازای توصیف کامل. یک سرور با ۹ ابزار که هرکدام طرح‌واره‌ی خروجی مفصل دارد، گران‌تر است از سروری با ۲۶ ابزار بی‌طرح‌واره.

هزینه‌ی هر سرور به تفکیک

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

حرف اول جدول، چیزی است که یک کلاینت باید بداندش: حالت باریک و حالت کامل یک بسته‌ی واحد نیستند. تفاوت ۲۱۲ با ۶٬۴۵۸ توکن ۳۰ برابر است و هر دو از یک بسته و یک نسخه می‌آیند. اگر کار شما باز کردن صفحه و خواندن کنسول است، حالت کامل شش هزار توکن را برای ۲۷ ابزاری که هرگز صدا نمی‌زنند به زمینه‌ی ثابت اضافه می‌کند.

حرف دوم، صورتحساب واقعی است. ۱۲٬۱۳۰ توکن در یک پنجره‌ی متن، وقتی کاربر یک پیام کوتاه می‌نویسد، قابل صرف‌نظر نیست. اگر هر پیام کاربر ۵۰۰ توکن باشد، فهرست ابزارها حدود ۲۴ برابرِ کل پیام است. برای یک نشست بیست‌نوبتی یعنی ۲۴۲ هزار توکن هزینه‌ی ثابت که هیچ‌کدامش تولید درآمد نکرده‌اند.

پنج معیار انتخاب که با عدد پشتیبانی می‌شوند

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

1. هزینه‌ی توصیف را مبنا بگذارید، نه تعداد ابزار. همان جدول دوم نشان می‌دهد نسبت ۱٫۰۳ تا ۲٫۲۳ برابر فقط از طرح‌واره‌ی خروجی می‌آید. معیار عددی‌اش: مجموع توکن فهرست، تقسیم بر تعداد فراخوانی واقعی در یک هفته‌ی کاری.
2. نسبت خواندن به نوشتن را ببینید. در گیت‌هاب بیشتر ابزارها خواندنی‌اند و همیشه در فهرست می‌مانند. اگر فقط خواندن می‌خواهید، واسطی که زیرمجموعه‌ی خواندنی را منتشر کند کسر هزینه می‌دهد.
3. قابلیت محدود کردن را پیش از نصب بسنجید. کروم این کار را با پرچم‌های دسته‌ای می‌کند و نتیجه‌اش همان ۲۱۲ توکن است. سروری بدون چنین پرچمی یعنی یا همه‌ی ابزارها را می‌پذیرید یا خودتان واسط می‌نویسید. در همین خانواده، راهنمای اجرای کدکس به‌عنوان سرور MCP دو ابزار منتشر می‌کند نه بیست‌وچهار، و همین محدودکردن عمدی است.
4. هزینه‌ی شکست را اندازه بگیرید، نه فقط هزینه‌ی موفقیت. در پست سرور کروم فراخوانی چهارم عمداً خراب بود و پیام خطا دقیقاً همان چیزی را گفت که لازم بود. سرور خوب در شکست هم مفید است؛ همین تفکیک میان خطایی که مدل می‌بیند و خطایی که فقط لاگ می‌شود، در راهنمای مدیریت خطای سرور به سه دسته تقسیم شده است.
5. فرایند جانبی را بشمارید. اسلک و پایگاه‌داده بدون توکن معتبر بالا نمی‌آیند؛ این یعنی پیش از اولین فراخوانی یک وابستگی بیرونی هم اضافه شده که در هیچ جدول توکنی دیده نمی‌شود.

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

مرز این اندازه‌گیری

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

دوم، کدگذار o200k_base برای خانواده‌ای از مدل‌هاست و لزوماً همان کدگذاری مدل شما نیست. نسبت‌ها معنادارتر از مطلق‌اند: گیت‌هاب در هر قالبی چهار برابر حالت باریک کروم است، فارغ از کدگذار.

سوم، ریتم انتشار دو سرور متفاوت است. بسته‌ی کروم ۱٫۱۰٫۱ است و آخرین تغییر رجیستری‌اش ۲۳ سپتامبر ۲۰۲۶، یعنی پنج روز پیش. بسته‌ی گیت‌هاب ۲۰۲۵٫۴٫۸ است؛ چهار عدد در نام نسخه یعنی نسخه‌گذاری‌اش با تقویم سالانه قفل شده و با ابزار تازه به‌روز نمی‌شود. یکی هفتگی تازه می‌شود و دیگری سالانه، و این مستقیماً روی تصمیم ادغام اثر می‌گذارد. برای همین پیش از ادغام، شماره‌ی نسخه را از خود رجیستری می‌خوانم و با بسته‌ی جداگانه‌ی انواع MCP و یادداشت‌های انتشار کتابخانه‌ی پایتون تطبیق می‌دهم.

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

منابع

1. سند قرارداد MCP نسخه‌ی ۲۰۲۶-۰۷-۲۸ — تعریف رسمی نام ابزار، توضیح، طرح‌واره‌ی ورودی و طرح‌واره‌ی خروجی
2. راهنمای کلاینت کتابخانه‌ی پایتون نسخه‌ی دو — اینکه کلاینت چه بخشی از طرح‌واره را به مدل می‌دهد
3. راهنمای مدیریت خطا در سرور — تفاوت خطایی که مدل می‌بیند با خطایی که فقط ثبت می‌شود
4. صفحه‌ی بسته‌ی mcp در رجیستری پایتون — نسخه و تاریخ انتشار
5. بسته‌ی انواع mcp-types — انواع جداگانه‌ی قرارداد
6. یادداشت‌های انتشار کتابخانه‌ی پایتون MCP — تغییرهای نسخه‌به‌نسخه
7. مخزن کتابخانه‌ی پایتون MCP — کد سرورهای نمونه و ابزار ساخت آن‌ها
8. راهنمای اجرای کدکس به‌عنوان سرور MCP — نمونه‌ای که با دو ابزار، بخش زیادی از فهرست را کنار می‌گذارد
9. افزونه‌ی کدکس برای کلاد کد — واگذاری کار به یک نشست کدکس دیگر