MCP Tool Search: چگونه 120 هزار توکن از schemaهای ابزار را موکول کردیم
بیستوچهار connector MCP حدود 60% از پنجره context ما را قبل از شروع هر کاری مصرف میکردند. روشن کردن Tool Search آن را به حدود 3 هزار توکن کاهش داد. خروجی /context قبل و بعد، به علاوه الگوهای تجمیع که کمک کردند را اینجا بخوانید.
هزینه پنهانی که هفتهها متوجه آن نشدیم
وقتی یک سرور MCP (Model Context Protocol) را در Claude Code نصب میکنید، ابزار به دست میآورید. ابزارهای زیادی. سرور MCP GitHub بهتنهایی 35 ابزار ارائه میدهد — برای issues، pull requests، شاخهها، نظرات، عرضهها، اجراهای workflow، deployments، هشدارهای امنیتی و موارد بیشتر.
چیز دیگری که بهطور پیشفرض دریافت میکنید، schema کامل JSON هر ابزار است که در شروع نشست به context تزریق میشود. نامها، توضیحات، انواع پارامترها، مقادیر enum، مثالها — همه آنها، قبل از اینکه یک prompt تایپ کنید.
ما در طول ساخت Statnive 24 سرور MCP را وصل کردیم. تا زمانی که نشستهایمان شروع به احساس فشرده شدن کرد به هزینه فکر نکردیم. سپس برای اولین بار /context را اجرا کردیم.
این پست قبل/بعد، یک flag است که 85% کار را انجام داد، و سه الگوی دیگر که کار را تمام کردند.
آنچه /context به ما نشان داد
اینجا تکه مرتبط از خروجی /context ما قبل از هر بهینهسازی است:
| سرور MCP | ابزار | توکن مصرف شده |
|---|---|---|
| GitHub | 35 | حدود 26,000 |
| Slack | 11 | حدود 21,000 |
| Jira | حدود 20 | حدود 17,000 |
| Playwright (browser automation) | 21 | حدود 13,647 |
| Context7 (library docs) | حدود 15 | حدود 8,000 |
| سایر 19 connector | حدود 190 | حدود 50,000 |
| مجموع سربار MCP | حدود 290 | حدود 135,000 |
این تقریباً 67% از کل پنجره context 200K صرف تعاریف ابزار برای ابزارهایی است که ممکن است در آن نشست استفاده نکنیم. الگویی که محققان جای دیگر مستند کردهاند برقرار است: میانگین سربار ابزار MCP حدود 500 تا 710 توکن به ازای هر ابزار است، و یک بار connector متوسط (24 سرور) بهطور معمول 48,000 تا 120,000 توکن را قبل از شروع هر کاری مصرف میکند. شدیدترین مورد مستند، سرور MCP Docker است: 135 ابزار، حدود 126,000 توکن بهتنهایی.
ما حدود 65 هزار توکن برای مکالمه واقعی، system prompt، ابزارهای داخلی، CLAUDE.md ما، metadata مهارتها و بافر auto-compact باقی داشتیم. به همین دلیل همه چیز فشرده احساس میشد.
Tool Search: یک flag که 85% کار را انجام داد
Claude Code v2.1.7 با MCP Tool Search عرضه شد. به جای تزریق schema هر ابزار در راهاندازی، Tool Search یک شاخص سبک حدود 5 هزار توکنی از نام و توضیحات ابزار میسازد. schema کامل هر ابزار منفرد فقط زمانی بارگذاری میشود که Claude واقعاً تصمیم به فراخوانی آن بگیرد. وقتی بارگذاری شد، در نشست cache میماند.
آزمون داخلی Anthropic کاهش از 134 هزار به حدود 5 هزار توکن — یک کاهش 85% را نشان داد. بهطور غیرمنتظره، دقت در ارزیابیهای MCP بالا رفت، نه پایین: Opus 4 از 49% به 74% در همان benchmark جهش کرد، احتمالاً به این دلیل که مدل در schemaهای ابزاری که نیازی نداشت غرق نمیشد.
Tool Search زمانی که توضیحات ابزار از حدود 10% پنجره context (حدود 20 هزار توکن) فراتر میروند بهطور خودکار فعال میشود. زیر آن آستانه خاموش میماند، با این فرض که نیازی به آن ندارید. ما بهخوبی بالای آستانه هستیم، بنابراین همیشه برای ما فعال است.
پس از فعال کردن آن، /context ما بهطور چشمگیری متفاوت بود:
| منبع | قبل | بعد |
|---|---|---|
| schemaهای ابزار MCP | حدود 135,000 | حدود 3,000 (فقط شاخص) |
| schemaهای ابزار MCP (در یک نشست که از 4 ابزار استفاده کرد) | حدود 135,000 | حدود 6,500 (شاخص + 4 schema بارگذاری شده) |
| context در دسترس برای کار | حدود 65,000 | حدود 190,000 |
گام راستیآزمایی که هرگز رد نمیکنیم: /context را در شروع نشست اجرا کنید و خطی که میگوید schemaهای ابزار موکول شدهاند یا Tool Search فعال است را تأیید کنید. اگر نباشد، بیهوده پول میدهید.
تجمیع انفجارهای CRUD
Tool Search بزرگترین اهرم منفرد بود، اما اگر ابزارهای منفرد توضیحات متورم داشته باشند یا سرورهای شما دهها ابزار تقریباً یکسان را افشا کنند کمک نمیکند.
ما یکی از سرورهای MCP داخلی خود را با استفاده از الگویی مستند در تحقیق بهنام تجمیع کنش-پارامتر بازسازی کردیم. API دهابزاری اصلی برای مدیریت issue:
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%. مدل همچنان بهدرستی مسیریابی میکند زیرا پارامتر کنش enumerated است و توضیح ابزار هر عملیات پشتیبانی شده را نام میبرد. ما نتایج مشابهی روی تجمیع خودمان دیدیم: حدود 9,800 توکن به 4,100 کاهش یافت.
حتی با موکول کردن بارگذاری schema توسط Tool Search، بار on-demand برای یک ابزار چاق بسیار کوچکتر از ده ابزار لاغر است، زیرا سربار schema تحت تسلط boilerplate تکراری است (تعاریف نوع، envelopeهای خطا، الگوهای صفحهبندی).
توضیحات را تهاجمی کوتاه کنید
طرف دیگر همان سکه. متن بازاریابی در توضیحات ابزار توکن واقعی هزینه دارد.
توضیحی مثل:
“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 نگه داشتیم
تعداد کمی از ابزارها را میخواهیم eager بارگذاری شوند زیرا تقریباً در هر نشست شلیک میشوند:
- Read، Write، Edit، Grep، Glob، Bash — داخلی، نه MCP، اما اصل یکسان است: فرکانس فراخوانی بالا، always-loaded را توجیه میکند.
- دو سرور MCP که چندین بار در هر نشست استفاده میکنیم — ابزار عرضه داخلی و سرور docs-fetching ما. schemaهای آنها در مجموع حدود 3,500 توکن است؛ بارگذاری on-demand 6+ بار در هر نشست بیشتر از تأخیر بازآوری هزینه دارد، در مقایسه با بارگذاری eager.
Tool Search یک allowlist eager به ازای هر سرور را به همین دلیل پشتیبانی میکند. بهطور جراحی استفاده کنید — هر ابزار eager سربار دائمی است.
خروجی را محدود کنید، یا شما را محدود میکند
متغیر محیطی MCP، MAX_MCP_OUTPUT_TOKENS بهطور پیشفرض 25,000 توکن به ازای هر پاسخ ابزار است. این برای یک پنجره 200K با یک فراخوانی ابزار به ازای هر نوبت سخاوتمندانه است. با 24 connector و ابزارهایی که در چند فراخوانی به ازای هر نوبت پخش میشوند، یک راه تضمینی برای پر کردن context با پاسخهای API خام است.
ما خود را روی 4,000 محدود کردیم و سرورهای پر-خروجیترین را ملزم کردیم از صفحهبندی سمت سرور و اشکال پاسخ summary-first پشتیبانی کنند. یک فراخوانی list-issues GitHub اکنون 20 مورد اول را با یک نشانگر has_more: true و یک توکن ادامه برمیگرداند به جای ریختن 200 issue در context. مدل میتواند در صورت نیاز درخواست بیشتر کند؛ معمولاً نمیکند.
برای workflowهای پیچیده چند-ابزاره، Programmatic Tool Calling (Claude کد ارکستراسیون مینویسد که در یک محیط sandboxed اجرا میشود، با فقط نتایج نهایی که وارد context میشوند) حدود 37% کاهش توکن را در آزمون داخلی Anthropic روی وظایف تحقیقمحور نشان داد. ما از آن برای یک workflow استفاده میکنیم — یک agent پرسشوپاسخ که به 6 سرور مستندات میرود — و صرفهجوییها برقرار هستند.
CLI > MCP برای ابزارهای کماستفاده
ضد شهودی اما واقعی: برای ابزارهایی که کم استفاده میکنید، یک دستور shell ارزانتر از یک سرور MCP است. gh، aws، gcloud، sentry-cli، wp — آنها از طریق ابزار Bash با صفر سربار context پایدار اجرا میشوند. توضیح ابزار Bash (که قبلاً بارگذاری شده) همه context است که میپردازید. متن کمک باینری CLI فقط در صورتی بارگذاری میشود که Claude آن را بخواند.
ما سه سرور MCP کماستفاده را کشیدیم و آنها را با استفاده CLI جایگزین کردیم. این بهتنهایی حدود 12,000 توکن از سربار baseline صرفهجویی کرد.
نقطه سربهسر تقریباً این است: آیا این ابزار بیش از یک بار در هر نشست معمولی شلیک میکند؟ اگر بله، MCP. اگر نه، CLI.
آنچه بهینه نکردیم
MAX_MCP_OUTPUT_TOKENSبه ازای فراخوانی است، نه به ازای نشست. یک سرور بدرفتار همچنان میتواند context را در طول چند نوبت پر کند. ما هنوز سقف به ازای نشست نداریم — این یک درخواست ویژگی Claude Code است، نه چیزی که بتوانیم محلی برطرف کنیم.- Tool Search روشن یا خاموش است. ما نمیتوانیم سرورهای MCP را به روش tier کردن مهارتها tier کنیم. همه 24 سرور ما بهطور یکنواخت از Tool Search عبور میکنند. برای سروری که تقریباً در هر نشست استفاده میکنیم، بارگذاری eager در واقع کارآمدتر میبود — اما نمیتوانیم بهطور انتخابی فقط آن یک سرور را eager بارگذاری کنیم بدون غیرفعال کردن Tool Search بهصورت سراسری.
- ما دقت مسیریابی را روی workloadهای خودمان بهدقت اندازه نگرفتیم. 49% به 74% Anthropic روی Opus 4 امیدوارکننده است، و ما در عمل شکستهای مسیریابی ندیدهایم، اما مجموعه benchmark نداریم تا اثبات کنیم بارگذاری موکول شده به همان خوبی بارگذاری eager برای وظایف خاص Statnive کار میکند.
گامهای عملی اگر امروز این کار را انجام میدهید
- در یک نشست تازه
/contextرا اجرا کنید. ببینید واقعاً چه چیزی بارگذاری شده است. - اگر schemaهای ابزار MCP از حدود 20 هزار توکن (10% پنجره) فراتر میروند، Tool Search باید بهطور خودکار فعال باشد. آن را از خروجی
/contextتأیید کنید. - سه connector سنگینترین خود را ممیزی کنید. منحنی Pareto بیرحم است — معمولاً 3 سرور 60%+ سربار MCP را مصرف میکنند.
- انفجارهای CRUD را در هر سرور MCP که کنترل میکنید تجمیع کنید.
- توضیحات هر ابزاری که توضیحش مثل کپی بازاریابی خوانده میشود را کوتاه کنید.
- ابزارهای کماستفاده را از MCP به CLI منتقل کنید.
MAX_MCP_OUTPUT_TOKENSرا به یک حد منطقی به ازای فراخوانی محدود کنید (ما از 4,000 استفاده میکنیم).
اگر میخواهید تصویر بزرگتر را — اینکه چگونه این با بهینهسازی CLAUDE.md و tier کردن مهارت متناسب است تا صرفهجوییهای ضربی ارائه دهد — با پست برجسته در این سری شروع کنید.
Statnive را امتحان کنید
تحلیلگری حریمخصوصیمحور WordPress، عرضه شده توسط تیمی که به جای رفتن هر توکن توجه میکند. Statnive را رایگان از WordPress.org نصب کنید — دادههای شما روی سرور شما باقی میماند.