یک رکورد 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) خودش فشردهتر است — عدد فارسی راستچین در یک ستون، مبلغی که فقط یکبار واحدش گفته شده، نه در هر سطر تکرار.
این چه ربطی به دستورهای آماده دارد؟
دستورهای آمادهی داشبورد (مثل «فروش امروز» یا «چکهای سررسیدشده») همین اصل را در سطح بالاتر پیاده میکنند: بهجای اینکه دستیار مجبور شود حدس بزند کدام فیلدها لازم است، خروجی از قبل به فیلدهای درست و خلاصهشده محدود است. جزئیات معماری دستورها و خروجی جدول فارسی در آموزش اتصال آمده.
