جستجوی ابزار در MCP: چطور بارگذاری 120 هزار توکن از طرحواره ابزارها را به تعویق انداختیم
بیستوچهار اتصال MCP پیش از شروع هر کاری حدود 60% از پنجره کانتکست ما را میبلعیدند. با روشنکردن Tool Search این رقم به حدود 3 هزار توکن رسید. در این مقاله خروجی /context را قبل و بعد میبینید، بهعلاوه الگوهای یکپارچهسازی که کمکمان کردند.
هزینه پنهانی که هفتهها متوجهش نشدیم
وقتی یک سرور MCP (Model Context Protocol) را در Claude Code نصب میکنید، ابزار به دست میآورید. کلی ابزار. خودِ سرور MCP مربوط به GitHub بهتنهایی 35 ابزار فراهم میکند — برای ایشوها، pull requestها، شاخهها، کامنتها، انتشارها، اجرای workflowها، استقرارها، هشدارهای امنیتی و موارد دیگر.
چیز دیگری هم که بهصورت پیشفرض گیرتان میآید این است که طرحواره کامل JSON هر ابزار در آغاز نشست به کانتکست تزریق میشود. نامها، توضیحات، نوع پارامترها، مقادیر enum، نمونهها — همهاش، پیش از آنکه حتی یک پرامپت تایپ کنید.
ما در طول ساختن Statnive، 24 سرور MCP وصل کردیم. تا وقتی نشستهایمان شروع به تنگشدن نکرد، اصلاً به هزینهاش فکر نکردیم. آن وقت بود که برای نخستینبار /context را اجرا کردیم.
این مقاله همان قبل و بعد است؛ همان یک تنظیمی که 85% کار را انجام داد، بهعلاوه سه الگوی دیگری که کار را تمام کردند.
/context چه چیزی نشانمان داد
این هم بخش مرتبطِ خروجی /context ما، پیش از هرگونه بهینهسازی:
| سرور MCP | ابزارها | توکن مصرفشده |
|---|---|---|
| GitHub | 35 | حدود 26,000 |
| Slack | 11 | حدود 21,000 |
| Jira | حدود 20 | حدود 17,000 |
| Playwright (خودکارسازی مرورگر) | 21 | حدود 13,647 |
| Context7 (مستندات کتابخانهها) | حدود 15 | حدود 8,000 |
| 19 اتصال دیگر | حدود 190 | حدود 50,000 |
| مجموع سربار MCP | حدود 290 | حدود 135,000 |
این یعنی تقریباً 67% از کل پنجره کانتکست 200K صرف تعریف ابزارهایی شده که شاید در آن نشست اصلاً به کارمان نیایند. الگویی که پژوهشگران جای دیگر مستند کردهاند هم همین را تأیید میکند: سربار میانگین هر ابزار MCP حدود 500 تا 710 توکن بهازای هر ابزار است، و یک بارِ اتصال متوسط (24 سرور) بهطور معمول پیش از شروع هر کاری 48,000 تا 120,000 توکن مصرف میکند. افراطیترین نمونهای که مستند شده، سرور MCP مربوط به Docker است: 135 ابزار، و بهتنهایی حدود 126,000 توکن.
برای خودِ گفتوگو، پرامپت سیستمی، ابزارهای داخلی، CLAUDE.md خودمان، فراداده اسکیلها و بافر auto-compact، تنها حدود 65 هزار توکن برایمان مانده بود. به همین دلیل بود که همهچیز تنگ به نظر میرسید.
Tool Search: همان یک تنظیمی که 85% کار را انجام داد
نسخه Claude Code v2.1.7 قابلیت MCP Tool Search را عرضه کرد. بهجای تزریق طرحواره هر ابزار در آغاز، Tool Search یک نمایه سبکِ حدوداً 5 هزار توکنی از نام و توضیح ابزارها میسازد. طرحواره کامل هر ابزار فقط وقتی بارگذاری میشود که Claude واقعاً تصمیم بگیرد آن را فراخوانی کند. این طرحواره پس از بارگذاری، تا پایان نشست در کش میماند.
آزمایشهای داخلی Anthropic کاهش از 134 هزار به حدود 5 هزار توکن — یعنی 85% کمتر را نشان داد. برخلاف انتظار، دقت در ارزیابیهای MCP بالا رفت، نه پایین: Opus 4 در همان معیار سنجش از 49% به 74% جهش کرد؛ احتمالاً به این دلیل که مدل دیگر در میان طرحواره ابزارهایی که به آنها نیازی نداشت غرق نمیشد.
Tool Search زمانی بهصورت خودکار فعال میشود که توضیحات ابزارها از حدود 10% پنجره کانتکست (حدود 20 هزار توکن) فراتر برود. زیر این آستانه خاموش میماند، با این فرض که به آن نیازی ندارید. ما خیلی بالاتر از این آستانه هستیم؛ بنابراین برای ما همیشه فعال است.
پس از فعالکردنش، خروجی /context ما بهشکل چشمگیری فرق کرد:
| منبع | قبل | بعد |
|---|---|---|
| طرحواره ابزارهای MCP | حدود 135,000 | حدود 3,000 (فقط نمایه) |
| طرحواره ابزارهای MCP (در نشستی که از 4 ابزار استفاده کرد) | حدود 135,000 | حدود 6,500 (نمایه + 4 طرحواره بارگذاریشده) |
| کانتکست در دسترس برای کار | حدود 65,000 | حدود 190,000 |
مرحلهای از بررسی که هرگز از آن نمیگذریم: /context را در آغاز نشست اجرا کنید و آن خطی را که میگوید طرحواره ابزارها به تعویق افتاده یا Tool Search فعال است، تأیید کنید. اگر اینطور نباشد، دارید بابت هیچ پول میدهید.
یکپارچهسازی انفجار CRUD
Tool Search بزرگترین اهرم یگانه بود، اما اگر تکتک ابزارها توضیحات پر و پیمان داشته باشند یا سرورهایتان دهها ابزار تقریباً یکسان عرضه کنند، کمکی نمیکند.
ما یکی از سرورهای MCP داخلیمان را با الگویی که در پژوهشها با نام یکپارچهسازی کنش-پارامتر مستند شده، بازسازی کردیم. این API اولیه با ده ابزار برای مدیریت ایشوها:
create_issue, update_issue, delete_issue, list_issues, get_issue,
add_comment, update_comment, delete_comment, list_comments, get_commentتبدیل شد به یک ابزار:
manage_issues({ action: "create" | "update" | "delete" | "list" | "get",
target: "issue" | "comment", ... })نتایج مستندشده از یک توسعهدهنده که این الگو را پیاده کرد: 20 ابزار از 14,214 توکن به 5,663 توکن رسید — یعنی 60% کاهش. مدل همچنان درست مسیریابی میکند، چون پارامتر کنش بهصورت enum فهرست شده و توضیح ابزار نام هر عملیات پشتیبانیشده را میبرد. ما هم در یکپارچهسازی خودمان نتیجهای مشابه دیدیم: تقریباً از 9,800 توکن به 4,100 توکن.
حتی با وجود Tool Search که بارگذاری طرحوارهها را به تعویق میاندازد، بارگذاری درلحظهٔ یک ابزار چاق خیلی کوچکتر از ده ابزار لاغر است؛ چون بیشترِ سربار طرحواره را همان قالب تکراری میسازد (تعریف نوعها، پوشش خطاها، الگوهای صفحهبندی).
توضیحات را بیرحمانه کوتاه کنید
روی دیگرِ همان سکه. متن تبلیغاتی در توضیح ابزارها توکن واقعی هزینه دارد.
توضیحی مثل این:
“Search the web using Tavily Search API. Best for factual queries requiring reliable sources and citations from authoritative web content. Handles complex topics with academic depth and provides comprehensive results with relevance scoring…”
برابر 87 توکن هزینه دارد. همان سیگنال مسیریابی در این یکی:
“Search using Tavily. Best for factual/academic topics with citations.”
برابر 12 توکن هزینه دارد. در میان 290 ابزار، صرفهجویی میانگین 50 توکن بهازای هر توضیح، حدود 14,500 توکن میشود.
قاعدهای که به کار میبریم: یک توضیح باید به Claude کمک کند تصمیم بگیرد این ابزار را فراخوانی کند یا نه، نه آنکه ابزار را تبلیغ کند. هر چیزی را که تصمیم مسیریابی را عوض نمیکند، حذف کنید.
کجا یک ابزار را مشتاق (eager) نگه داشتیم
تعداد کمی از ابزارها را میخواهیم مشتاقانه بارگذاری شوند، چون تقریباً در هر نشست شلیک میشوند:
- Read، Write، Edit، Grep، Glob، Bash — اینها داخلی هستند، نه MCP، اما اصلش یکی است: فراوانی بالای فراخوانی، بارگذاری همیشگی را توجیه میکند.
- دو سرور MCP که در هر نشست چندبار به کار میبریم — ابزار انتشار داخلیمان و سرور دریافت مستنداتمان. طرحوارههایشان رویهم حدود 3,500 توکن است؛ بارگذاری درلحظهای آنها 6 بار یا بیشتر در هر نشست، بابت تأخیر دریافت دوباره گرانتر از آن چیزی تمام میشد که بارگذاری مشتاقانه صرفهجویی میکند.
Tool Search دقیقاً به همین دلیل، یک فهرست مجاز مشتاقانه بهازای هر سرور را پشتیبانی میکند. با دقت جراحی از آن استفاده کنید — هر ابزار مشتاق، سرباری دائمی است.
خروجی را محدود کنید، وگرنه او شما را محدود میکند
متغیر محیطی MCP با نام MAX_MCP_OUTPUT_TOKENS بهصورت پیشفرض روی 25,000 توکن بهازای هر پاسخ ابزار تنظیم است. این رقم برای یک پنجره 200K با یک فراخوانی ابزار در هر نوبت، سخاوتمندانه است. اما با 24 اتصال و ابزارهایی که در هر نوبت روی چند فراخوانی پخش میشوند، راهی تضمینی است برای پُرکردن کانتکست با پاسخهای خام API.
ما رقم خودمان را روی 4,000 محدود کردیم و از پُرخروجیترین سرورها خواستیم صفحهبندی سمتسرور و پاسخهای خلاصهاول را پشتیبانی کنند. حالا یک فراخوانی فهرستکردن ایشو در GitHub، بهجای ریختن 200 ایشو در کانتکست، 20 مورد نخست را بههمراه نشانگر has_more: true و یک توکن ادامه برمیگرداند. مدل اگر لازم باشد میتواند موارد بیشتری بخواهد؛ اما معمولاً نمیخواهد.
برای گردشکارهای پیچیده چندابزاری، Programmatic Tool Calling (Claude کد هماهنگسازی مینویسد که در محیطی ایزولهشده اجرا میشود و فقط نتیجه نهایی وارد کانتکست میشود) در آزمایشهای داخلی Anthropic روی کارهای پژوهشمحور، حدود 37% کاهش توکن نشان داد. ما برای یک گردشکار از آن استفاده میکنیم — یک عامل پرسشوپاسخ که به 6 سرور مستندات میرسد — و این صرفهجویی پابرجاست.
برای ابزارهای کممصرف، CLI > MCP است
برخلاف انتظار، اما واقعی: برای ابزارهایی که بهندرت به کار میبرید، یک فرمان پوسته ارزانتر از یک سرور MCP است. ابزارهایی مثل gh، aws، gcloud، sentry-cli، wp از طریق ابزار Bash اجرا میشوند و هیچ سربار دائمی روی کانتکست ندارند. توضیح ابزار Bash (که از پیش بارگذاری شده) تنها کانتکستی است که بابتش پول میدهید. متن راهنمای باینریِ CLI هم فقط وقتی بارگذاری میشود که Claude آن را بخواند.
ما سه سرور MCP کممصرف را برداشتیم و جایشان از CLI استفاده کردیم. همین یک کار، حدود 12,000 توکن از سربار پایه را صرفهجویی کرد.
نقطه سربهسر تقریباً همین است: آیا این ابزار در یک نشست معمول بیش از یکبار شلیک میشود؟ اگر بله، MCP. اگر نه، CLI.
چه چیزهایی را بهینه نکردیم
MAX_MCP_OUTPUT_TOKENSبهازای هر فراخوانی است، نه هر نشست. یک سرور بدرفتار همچنان میتواند در طول نوبتهای زیاد، کانتکست را سرریز کند. ما هنوز سقفی بهازای هر نشست نداریم — این یک درخواست ویژگی برای Claude Code است، نه چیزی که بشود محلی درستش کرد.- Tool Search یا روشن است یا خاموش. ما نمیتوانیم سرورهای MCP را طبقهبندی کنیم، آنطور که اسکیلها را طبقهبندی میکنیم. هر 24 سرور ما بهیکشکل از Tool Search میگذرند. برای سروری که تقریباً در هر نشست به کارش میبریم، بارگذاری مشتاقانه در واقع کارآمدتر میبود — اما نمیتوانیم بدون خاموشکردن سراسری Tool Search، فقط طرحواره همان یک سرور را بهصورت گزینشی مشتاقانه بارگذاری کنیم.
- دقت مسیریابی را روی بار کاری خودمان با دقت اندازه نگرفتیم. نتیجه 49% ← 74% Anthropic روی Opus 4 امیدوارکننده است و ما در عمل خطای مسیریابی ندیدهایم، اما مجموعهای از معیارهای سنجش نداریم که ثابت کند بارگذاری بهتعویقافتاده برای کارهای مخصوص Statnive بهخوبیِ بارگذاری مشتاقانه عمل میکند.
گامهای عملی اگر امروز این کار را انجام میدهید
/contextرا در یک نشست تازه اجرا کنید. ببینید واقعاً چه چیزی بارگذاری شده است.- اگر طرحواره ابزارهای MCP از حدود 20 هزار توکن (10% پنجره) فراتر میرود، Tool Search باید بهصورت خودکار فعال باشد. از روی خروجی
/contextآن را تأیید کنید. - سه اتصال سنگینترتان را بررسی کنید. منحنی پارتو بیرحم است — معمولاً 3 سرور بیش از 60% سربار MCP را مصرف میکنند.
- در هر سرور MCP که خودتان کنترلش میکنید، انفجار CRUD را یکپارچه کنید.
- توضیح هر ابزاری را که مثل متن تبلیغاتی خوانده میشود، کوتاه کنید.
- ابزارهای کممصرف را از MCP به CLI منتقل کنید.
- مقدار
MAX_MCP_OUTPUT_TOKENSرا روی یک سقف منطقی بهازای هر فراخوانی محدود کنید (ما از 4,000 استفاده میکنیم).
اگر تصویر بزرگتر را میخواهید — اینکه این کار چطور با بهینهسازی CLAUDE.md و طبقهبندی اسکیلها ترکیب میشود تا صرفهجوییهای چندبرابری بهبار بیاورد — از مقاله اصلی این مجموعه شروع کنید.
Statnive را امتحان کنید
آنالیتیکس وردپرس با محوریت حریم خصوصی، که تیمی آن را عرضه کرده که حواسش به جایجای رفتن هر توکن هست. Statnive را رایگان از WordPress.org نصب کنید — دادههایتان روی سرور خودتان میماند.