پاسخ کوتاه: هر کلید MCP باید سه سقف داشته باشد: سقف توکن روزانه (مثلاً ۱۰۰هزار توکن)، سقف تعداد فراخوانی در ساعت و سقف مانده کیف‌پول. بدون این سه، یک کلاینت گمشده می‌تواند کل اعتبار AI شرکت را در یک حلقه‌ی اشتباه بسوزاند. جزئیات پیاده‌سازی سقف‌ها در همین مقاله.
بودجه توکن چطور محاسبه می‌شود؟
| مصرف | تخمین توکن | کنترل |
|---|---|---|
| خواندن گزارش فروش ماه | ۲-۵ هزار | سقف روزانه per-key |
| جستجوی مشتریان | ۵۰۰-۱,۵۰۰ | سقف ساعت |
| ثبت سفارش | ۱-۲ هزار | تایید دو مرحله‌ای |
کلید با بودجه بسازید: سرور MCP ابرک و کیف‌پول ریالی AI.
سجل sale.order في Odoo يضم نحو 80 حقلًا. إذا أعادت أداة القراءة كل هذه الحقول لكل سجل، فقد يصل الرد لقائمة من 20 سجلًا إلى آلاف الرموز (توكن) — قبل أن يكتب النموذج كلمة واحدة عنها. هذه الرموز تمثل تكلفة مالية (معظم عملاء MCP يستخدمون واجهة برمجية مدفوعة للنموذج اللغوي) ومساحة أيضًا: نافذة السياق محدودة، وامتلاؤها بحقول غير ذات صلة يعني مساحة أقل للمحادثة نفسها.
ماذا يعني «الوعي بميزانية التوكن»؟
أي أن الأداة تسأل قبل الرد: «هل نحتاج فعلًا كل هذه الحقول؟» — بدلًا من انتظار أن يُصفّيها العميل بنفسه. إذا لم يحدد العميل الحقول، فبدلًا من السلوك الافتراضي «كل شيء»، تُعيد الأداة مجموعة صغيرة وذات معنى من الحقول (الاسم، الحالة، المبلغ، التاريخ) وتوضح أن هناك حقولًا إضافية يمكن الوصول إليها بطلب ثانٍ. وهذا عكس تمامًا السلوك الافتراضي لمعظم أغلفة XML-RPC البسيطة التي تمرر fields_get() كاملة لأن بناءها أسهل.
ماذا تقول مواصفات MCP نفسها؟
صمّمت مواصفات البروتوكول tools/list صراحة لتكون قابلة للتصفّح بالصفحات — أي أن قائمة الأدوات نفسها ليست مقرراً نقلها كاملة دفعة واحدة، بل تُقسَّم إلى أجزاء أصغر باستخدام cursor. ويجب تكرار الفلسفة نفسها في مخرجات كل أداة: ابدأ صغيراً، وقدّم المزيد عند الحاجة.
كيف طبّق خادم MCP من Abrak هذا؟
suggest_fields— يقترح الحقول ذات الصلة بالسؤال قبل القراءة؛ ويمكن للنموذج أن يطلب هذه الحقول فقط فيread_records.list_fields— القائمة الكاملة لحقول نموذج معيّن مع النوع والتسمية، لاستخدامها عند الحاجة الفعلية للاستكشاف — لا كافتراضي لكل عملية قراءة.- تقبل أدوات القراءة (
read_records،search_read) المعاملfields، ودون تحديده تُعيد مجموعة افتراضية صغيرة، لا النتيجة الكاملة لـfields_get(). - المخرجات الجدولية/البطاقية (بدل جدار JSON) أكثر إيجازًا بطبيعتها — رقم فارسي محاذٍ لليمين في عمود واحد، ومبلغ تُذكر وحدته مرة واحدة فقط لا في كل سطر.
ما علاقة هذا بالأوامر الجاهزة؟
الأوامر الجاهزة في لوحة المعلومات (مثل «مبيعات اليوم» أو «الشيكات المستحقة») تطبّق المبدأ نفسه على مستوى أعلى: فبدلًا من أن يضطر المساعد إلى تخمين الحقول المطلوبة، يكون الإخراج محصورًا مسبقًا في الحقول الصحيحة وملخَّصًا. تفاصيل بنية الأوامر وإخراج الجدول بالفارسية في دليل الاتصال وارد.
هزینهٔ سه الگوی رایج ابزار
تفاوت یک ابزار آگاه به بودجه و یک ابزار ساده، در یک اجرا دیده نمی‌شود؛ در هزار اجرا خودش را نشان می‌دهد.
| الگوی ابزار | چه برمی‌گرداند | اثر روی هزینه |
|---|---|---|
| برگرداندن کل رکورد | همهٔ فیلدها، حتی بی‌ربط‌ها | چند برابر شدن توکن ورودی |
| برگرداندن فهرست بدون سقف | هر تعداد ردیف که پیدا شود | غیرقابل پیش‌بینی؛ یک کوئری می‌تواند بودجهٔ روز را ببلعد |
| آگاه به بودجه | فیلدهای لازم، با سقف و خلاصه | قابل پیش‌بینی و قابل بودجه‌بندی |
چهار قاعدهٔ طراحی ابزار کم‌هزینه
- فیلد صریح، نه ستاره: ابزار باید فیلدهایی که برمی‌گرداند را از قبل تعریف کند، نه کل رکورد را.
- سقف پیش‌فرض روی تعداد ردیف: با امکان صفحه‌بندی، نه با برگرداندن همه‌چیز.
- سنجش حجم پیش از پاسخ: اگر خروجی از سقف رد شد، به‌جای بریدن کور، خلاصه بده و راه محدودکردن را پیشنهاد کن.
- خطای معنادار: «نتیجه بیش از حد بزرگ است، بازهٔ تاریخ را محدود کنید» بسیار ارزان‌تر از برگرداندن ده هزار ردیف است.
چطور بودجه را واقعی پایش کنید
سه عدد هفتگی: میانگین توکن ورودی به‌ازای هر فراخوانی ابزار، پرهزینه‌ترین ابزار، و نسبت فراخوانی‌هایی که به سقف خورده‌اند. عدد سوم معمولاً مستقیماً به یک ابزار بدطراحی اشاره می‌کند. اصلاح همان یک ابزار اغلب بیشتر از تغییر مدل صرفه‌جویی می‌کند.
ارتباط این موضوع با معماری چندمستأجره در چرا اکثر سرورهای MCP روی ERP چندمستأجره خراب می‌شوند، کاربردهای واقعی در ۷ کاربرد سرور MCP روی اودو و سرویس در MCP برای اودوو.
