پاسخ کوتاه: هر کلید MCP باید سه سقف داشته باشد: سقف توکن روزانه (مثلاً ۱۰۰هزار توکن)، سقف تعداد فراخوانی در ساعت و سقف مانده کیف‌پول. بدون این سه، یک کلاینت گمشده می‌تواند کل اعتبار AI شرکت را در یک حلقه‌ی اشتباه بسوزاند. جزئیات پیاده‌سازی سقف‌ها در همین مقاله.
بودجه توکن چطور محاسبه می‌شود؟
| مصرف | تخمین توکن | کنترل |
|---|---|---|
| خواندن گزارش فروش ماه | ۲-۵ هزار | سقف روزانه per-key |
| جستجوی مشتریان | ۵۰۰-۱,۵۰۰ | سقف ساعت |
| ثبت سفارش | ۱-۲ هزار | تایید دو مرحله‌ای |
کلید با بودجه بسازید: سرور MCP ابرک و کیف‌پول ریالی AI.
یک رکورد sale.order در اودو نزدیک به ۸۰ فیلد دارد. اگر ابزار خواندن، همه‌ی این فیلدها را برای هر رکورد برگرداند، برای یک لیست ۲۰تایی، پاسخ می‌تواند هزاران توکن باشد — پیش از آنکه مدل حتی یک کلمه درباره‌ی آن بنویسد. این توکن‌ها هم پول‌اند (اکثر کلاینت‌های MCP از API مدل زبانی پولی استفاده می‌کنند) و هم فضا: پنجره‌ی زمینه محدود است، و پر شدنش با فیلدهای بی‌ربط یعنی جای کمتر برای خودِ مکالمه.
«آگاه به بودجه‌ی توکن» یعنی چه؟
یعنی ابزار پیش از پاسخ می‌پرسد «واقعاً به همه‌ی این فیلدها نیاز هست؟» — نه اینکه صبر کند کلاینت خودش فیلدها را فیلتر کند. اگر کلاینت فیلد مشخص نکرده، ابزار به‌جای رفتار پیش‌فرض «همه‌چیز»، مجموعه‌ای کوچک و معنادار از فیلدها (نام، وضعیت، مبلغ، تاریخ) را برمی‌گرداند و می‌گوید چند فیلد دیگر هم هست که با یک درخواست دوم قابل دسترسی‌اند. این دقیقاً برعکس رفتار پیش‌فرض بیشتر wrapperهای ساده‌ی XML-RPC است که fields_get() کامل را پاس می‌دهند چون ساختنش راحت‌تر است.
مشخصات MCP خودش چه می‌گوید؟
مشخصات پروتکل صراحتاً tools/list را صفحه‌بندی‌پذیر طراحی کرده — یعنی حتی فهرست خودِ ابزارها هم قرار نیست یک‌جا و کامل منتقل شود، بلکه با cursor به بخش‌های کوچک‌تر تقسیم می‌شود. همین فلسفه باید در خروجی هر ابزار تکرار شود: کوچک شروع کن، وقتی لازم شد بیشتر بده.
سرور MCP ابرک این را چطور پیاده کرده؟
suggest_fields— پیش از خواندن، فیلدهای مرتبط با سؤال را پیشنهاد می‌دهد؛ مدل می‌تواند فقط همان‌ها را درread_recordsبخواهد.list_fields— فهرست کامل فیلدهای یک مدل با نوع و برچسب، برای وقتی که واقعاً کاوش لازم است — نه پیش‌فرض هر خواندنی.- ابزارهای خواندن (
read_records،search_read) پارامترfieldsرا می‌پذیرند و بدون آن به یک مجموعه‌ی کوچک پیش‌فرض برمی‌گردند، نه بهfields_get()کامل. - خروجی جدولی/کارتی (به‌جای دیوار JSON) خودش فشرده‌تر است — عدد فارسی راست‌چین در یک ستون، مبلغی که فقط یک‌بار واحدش گفته شده، نه در هر سطر تکرار.
این چه ربطی به دستورهای آماده دارد؟
دستورهای آماده‌ی داشبورد (مثل «فروش امروز» یا «چک‌های سررسیدشده») همین اصل را در سطح بالاتر پیاده می‌کنند: به‌جای اینکه دستیار مجبور شود حدس بزند کدام فیلدها لازم است، خروجی از قبل به فیلدهای درست و خلاصه‌شده محدود است. جزئیات معماری دستورها و خروجی جدول فارسی در آموزش اتصال آمده.
هزینهٔ سه الگوی رایج ابزار
تفاوت یک ابزار آگاه به بودجه و یک ابزار ساده، در یک اجرا دیده نمی‌شود؛ در هزار اجرا خودش را نشان می‌دهد.
| الگوی ابزار | چه برمی‌گرداند | اثر روی هزینه |
|---|---|---|
| برگرداندن کل رکورد | همهٔ فیلدها، حتی بی‌ربط‌ها | چند برابر شدن توکن ورودی |
| برگرداندن فهرست بدون سقف | هر تعداد ردیف که پیدا شود | غیرقابل پیش‌بینی؛ یک کوئری می‌تواند بودجهٔ روز را ببلعد |
| آگاه به بودجه | فیلدهای لازم، با سقف و خلاصه | قابل پیش‌بینی و قابل بودجه‌بندی |
چهار قاعدهٔ طراحی ابزار کم‌هزینه
- فیلد صریح، نه ستاره: ابزار باید فیلدهایی که برمی‌گرداند را از قبل تعریف کند، نه کل رکورد را.
- سقف پیش‌فرض روی تعداد ردیف: با امکان صفحه‌بندی، نه با برگرداندن همه‌چیز.
- سنجش حجم پیش از پاسخ: اگر خروجی از سقف رد شد، به‌جای بریدن کور، خلاصه بده و راه محدودکردن را پیشنهاد کن.
- خطای معنادار: «نتیجه بیش از حد بزرگ است، بازهٔ تاریخ را محدود کنید» بسیار ارزان‌تر از برگرداندن ده هزار ردیف است.
چطور بودجه را واقعی پایش کنید
سه عدد هفتگی: میانگین توکن ورودی به‌ازای هر فراخوانی ابزار، پرهزینه‌ترین ابزار، و نسبت فراخوانی‌هایی که به سقف خورده‌اند. عدد سوم معمولاً مستقیماً به یک ابزار بدطراحی اشاره می‌کند. اصلاح همان یک ابزار اغلب بیشتر از تغییر مدل صرفه‌جویی می‌کند.
ارتباط این موضوع با معماری چندمستأجره در چرا اکثر سرورهای MCP روی ERP چندمستأجره خراب می‌شوند، کاربردهای واقعی در ۷ کاربرد سرور MCP روی اودو و سرویس در MCP برای اودوو.
