حدود المعدل والترقيم في خادم MCP الخاص بـ Forktastic

تحتاج كل واجهة برمجة تطبيقات إلى حدود للمعدل. يفرض خادم Forktastic MCP عدد 60 طلبًا في الدقيقة و 5000 طلب في اليوم لكل رمز، مع ترقيم يعتمد على الإزاحة في نقاط نهاية القائمة. هذه هي الوثيقة المرجعية - ما هي الحدود، وكيف تتصرف عند تجاوزها، وكيف يعمل الترقيم، وكيفية تصميم الوكلاء الذين يبقون ضمن الحدود.

الأرقام

• 60 طلبًا في الدقيقة لكل رمز. يؤدي تجاوز 60 في نافذة منزلقة مدتها 60 ثانية إلى إرجاع HTTP 429.
• 5000 طلب في اليوم لكل رمز. النافذة اليومية هي من منتصف ليل UTC إلى منتصف ليل UTC. يؤدي التجاوز إلى إرجاع HTTP 429 حتى تتم إعادة تعيين المجموعة.
• لكل رمز، وليس لكل حساب. إذا كان لديك ثلاثة PATs، فلديك 3 × 60/دقيقة و 3 × 5000/يوم.

كيف يبدو استجابة 429

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json

{
  "error": "rate_limited",
  "limit_type": "per_minute",
  "reset_in_seconds": 12
}

يخبرك رأس Retry-After بالمدة التي يجب أن تنتظرها. بالنسبة للحدود لكل دقيقة، عادةً ما تكون 0-60 ثانية. بالنسبة للحدود لكل يوم، يمكن أن تكون ساعات.

الترقيم

تستخدم نقاط نهاية القائمة (search_recipes، list_cookbooks، search_cookbooks، get_trending) ترقيمًا يعتمد على الإزاحة:

• limit - العناصر في الصفحة. الافتراضي 20، الحد الأقصى 100.
• offset - عدد العناصر المراد تخطيها. الافتراضي 0.

للتنقل عبر النتائج، قم بزيادة الإزاحة بمقدار الحد في كل استدعاء. لجلب جميع العناصر، استمر في الترقيم حتى تحصل على صفحة قصيرة (عناصر أقل من الحد)، مما يعني أنك وصلت إلى النهاية.

سلوك تجاوز الإزاحة PGRST103

إذا قمت بتعيين الإزاحة بعد العدد الإجمالي، فإن الإصدارات القديمة من واجهة برمجة التطبيقات تُرجع خطأ HTTP 416 (PGRST103). السلوك الحالي: تجاوز الإزاحة يُرجع مصفوفة فارغة، وليس خطأ. هذا يجعل الترقيم حتى الفراغ يعمل بشكل نظيف. لا تعتمد على أخطاء PGRST103 كإشارة نهاية القائمة - استخدم طول المصفوفة.

أنماط تصميم الوكيل التي تبقى ضمن الحدود

التخزين المؤقت ممكن. إذا كان وكيلك يقرأ نفس قائمة كتب الطبخ كل ساعة، فقم بتخزينها مؤقتًا. تتغير البيانات ببطء.

قراءة الدفعات. استخدم البحث بحد أكبر بدلاً من التكرار بـ limit=1. استدعاء search_recipes واحد مع limit=100 هو طلب واحد؛ 100 استدعاء مع limit=1 هو 100 طلب.

احترم Retry-After. عندما تصل إلى 429، انتظر الوقت المحدد الذي يقوله الرأس. لا تحاول إعادة المحاولة بقوة - فهذا يزيد من الخنق.

وظائف الخلفية المتداخلة. إذا كان وكيل خطة الوجبات الأسبوعية الخاص بك يعمل كل يوم اثنين في الساعة 8 صباحًا وكذلك يفعل ألف شخص آخر، فستصلون جميعًا إلى حد المعدل. أضف ارتعاشًا عشوائيًا صغيرًا (±5 دقائق) حتى ينتشر الحمل.

هل ستتغير هذه الحدود؟

من المحتمل أن يكون ذلك صعوديًا، إذا كانت أنماط الاستخدام تبرر ذلك. الأرقام الحالية متحفظة لخادم MCP جديد تمامًا في الإنتاج. نفضل أن نبدأ بضيق ثم نرخي بدلاً من أن نبدأ بشكل فضفاض ونضطر إلى التشديد بأثر رجعي (مما يكسر كل وكيل كان يعتمد على حدود أعلى).

ماذا يحدث إذا كنت بحاجة إلى حدود أعلى

في الوقت الحالي: قسّم عبء العمل الخاص بك عبر PATs متعددة (لكل منها مجموعتها الخاصة)، أو قم بتجميع عمليات القراءة الخاصة بك بشكل أكثر فعالية. المستقبل: من المحتمل أن نقدم حدودًا قائمة على المستويات للمستخدمين ذوي الاحتياجات المشروعة ذات الحجم الأكبر.

إلى أين تذهب بعد ذلك

للحصول على مرجع الأدوات، 7 أدوات MCP. لإدارة PAT، شرح PAT. لإعداد Claude، شرح Claude. لركيزة MCP، دليل ركيزة MCP.