TokenLab for Agents: نماذج قابلة للقراءة آلياً، الأسعار، SDKs، و MCP

يُعد TokenLab MCP خادم بروتوكول سياق النموذج (MCP) للقراءة فقط، والذي يمنح وكيل البرمجة وصولاً مباشراً ومنظماً إلى كتالوج نماذج TokenLab العام، والأسعار، ونظرة عامة على الـ API قبل أن يكتب سطراً واحداً من كود التكامل. فهو يجيب على أسئلة الاستكشاف — ما هي معرفات النماذج (model IDs) الموجودة حالياً، وما تكلفتها، وما هي الوسائط التي تدعمها — ولا يقوم باستدعاء واجهات برمجة تطبيقات الاستدلال المدفوعة نيابة عنك.

العديد من أخطاء تكامل الوكلاء لا تبدأ عند أول استدعاء للـ API، بل تبدأ في وقت أبكر، عندما يختار الوكيل معرف نموذج من مثال قديم، أو ذاكرة مخزنة مؤقتاً، أو برنامج تعليمي مر عليه ستة أشهر، ولا يكتشف عدم التطابق إلا بعد ظهور خطأ 404 أو مفاجأة في التسعير.

وكلاء البرمجة يكتبون بسرعة. وهم لا يقرأون دائماً أولاً. إلى جانب TokenLab MCP، تنشر TokenLab ملف llms.txt مدمج، وملف llms-full.txt أكثر تفصيلاً، وملفات JSON لبيانات النماذج العامة — وهي نفس واجهات كتالوج النماذج والتسعير التي يمكنك تصفحها بنفسك — حتى يتمكن الوكيل من التحقق من معرفات النماذج الحالية وتكاليفها قبل أن يقوم بترميز أي شيء بشكل ثابت (hardcode).

تغطي هذه المقالة ماهية هذه الواجهات، وما ليست عليه، وكيفية ربط الوكيل لاستخدامها قبل أن يقوم بترميز اسم نموذج بشكل ثابت. للحصول على المرجع الكامل لنقاط النهاية، راجع وثائق التكامل.

أبرز النقاط

• تنشر TokenLab نظرات عامة على الـ API قابلة للقراءة من قبل الوكلاء في api.tokenlab.sh/llms.txt و llms-full.txt، مع إعادة توجيه نطاق الويب إلى نفس المصدر.
• تمنح ملفات مركز بيانات النماذج العامة (JSON للكتالوج، JSON للأحدث، JSON للاتجاهات، وملخص markdown) الوكلاء لقطة قابلة للاستعلام عما تقدمه TokenLab حالياً.
• يكشف خادم TokenLab MCP عن list_models، وget_model، وget_model_pricing، وget_api_overview — وهو للقراءة فقط. ولا يقوم بعمل وكيل (proxy) للاستدلال المدفوع.
• توصي الوثائق العامة بأن يقوم الوكلاء باستدعاء /v1/models أو قراءة llms.txt قبل ترميز اسم نموذج بشكل ثابت، واستخدام تصفية recommended_for للمهام غير المتعلقة بالدردشة مثل الصور، أو الفيديو، أو التضمين (embedding).
• تجنب قراءة نقاط نهاية النماذج والأسعار قبل إعادة محاولة طلب فاشل غير متعلق بالدردشة عمليات الاستدعاء الفاشلة المتكررة ضد عائلة النماذج الخاطئة.

لماذا يختار الوكلاء معرفات نماذج قديمة في المقام الأول

يقوم وكلاء البرمجة بإنشاء معرفات النماذج بناءً على ما تعلموه أثناء التدريب، وليس بناءً على ما هو متاح حالياً. بيانات التدريب تلك لها تاريخ قطع، لذا فإن إحساس الوكيل الداخلي بـ "النموذج الحالي" ثابت عند كل ما كان صحيحاً عندما تم تحديث أوزانه آخر مرة. عندما تطلب من وكيل استدعاء API نموذج، فإنه سيصل بثقة إلى المعرف الذي يتذكره — حتى لو تم تغيير اسم ذلك المعرف، أو إيقافه، أو استبداله منذ ذلك الحين.

هذا ليس خطأ في منطق الوكيل؛ إنه قيد هيكلي لأي نظام يعتمد على المعرفة المحفوظة بدلاً من البحث المباشر. الحل ليس في توجيه (prompt) أكثر ذكاءً — بل في منح الوكيل مكاناً للتحقق قبل أن يكتب الكود.

هذا هو الغرض من ملفات بيانات النماذج والـ API الخاصة بـ TokenLab. قبل إنشاء طلب، يمكن للوكيل (أو الشخص الذي يراجع مخرجاته) الاستعلام عن نقطة نهاية مباشرة للتأكد من أن معرف النموذج موجود بالفعل، وما هي الوسائط التي يدعمها، وما تكلفتها — بدلاً من الوثوق باسم مستمد من الذاكرة.

نقطة النهاية	الغرض
https://tokenlab.sh/model-data/catalog.json	كتالوج كامل للنماذج المتعقبة، مهيكل للبحث البرمجي
https://tokenlab.sh/model-data/latest.json	قائمة النماذج الحالية بتنسيق خفيف وصديق للوكلاء
https://tokenlab.sh/en/models	متصفح نماذج قابل للقراءة البشرية
https://tokenlab.sh/en/pricing	التسعير الحالي حسب النموذج والوسائط

أي منشور مدونة — بما في ذلك هذا المنشور — هو لقطة. إنه يعكس ما كان صحيحاً وقت كتابته، وسوف يصبح قديماً بنفس الطريقة التي تصبح بها بيانات تدريب الوكيل قديمة. نقاط النهاية المباشرة لا تعاني من هذه المشكلة: فهي تعكس ما هو صحيح في الوقت الحالي، ولهذا السبب فهي الشيء الأكثر أماناً للتحقق منه قبل شحن الكود، وليس مقالاً ثابتاً.

ما تكشفه TokenLab لاستكشاف الوكلاء

طبقة llms.txt

https://api.tokenlab.sh/llms.txt هي نظرة عامة مدمجة وقابلة للقراءة من قبل الوكلاء على الـ API: ما هي نقاط النهاية الموجودة، وكيف يبدو الطلب، وأين يمكن العثور على تفاصيل أعمق. لقد صُممت لتكون قصيرة بما يكفي ليتمكن الوكيل من قراءتها في نافذة سياق واحدة دون استهلاك ميزانية رموز (token) كبيرة لمجرد توجيه نفسه.

https://api.tokenlab.sh/llms-full.txt هي النسخة الأكثر تفصيلاً — المزيد من تفاصيل نقاط النهاية، والمزيد من الأمثلة، والمزيد من مساحة السطح التي يحتاجها الوكيل قبل إنشاء تكامل يعمل بدلاً من مسودة أولية.

إذا وصلت إلى نطاق الويب بدلاً من مضيف الـ API، فإن tokenlab.sh/llms.txt و tokenlab.sh/llms-full.txt يعيدان التوجيه إلى نفس المصادر المستضافة على الـ API. هذا مهم للوكلاء: أي نقطة دخول يقومون بالزحف إليها أو جلبها، فإنهم يصلون إلى نفس النص الأساسي، وليس نسختين متباعدتين.

مركز بيانات النماذج

بعيداً عن النظرة العامة النصية، تنشر TokenLab ملفات JSON مهيكلة يمكن للوكيل (أو برنامج البناء) سحبها مباشرة:

• https://tokenlab.sh/model-data/catalog.json — كتالوج النماذج الأكثر تفصيلاً.
• https://tokenlab.sh/model-data/latest.json — لقطة موجهة نحو ما هو حالي في الوقت الراهن.
• https://tokenlab.sh/model-data/summary.md — ملخص markdown قابل للقراءة من قبل البشر والوكلاء، مفيد عندما تريد مقارنة سريعة مقابل ما يقوم الكود الخاص بك بترميزه حالياً بشكل ثابت.

هذه ملفات ثابتة قابلة للجلب. يمكن للوكيل الذي يقوم ببناء ملف تكوين، أو قالب .env، أو قائمة منسدلة لاختيار النموذج سحب ملف JSON مباشرة بدلاً من مطالبة شخص بلصق قائمة نماذج ستصبح قديمة مرة أخرى في غضون أسبوعين.

خادم MCP — للقراءة فقط، ويستحق أن نكون دقيقين بشأن ذلك

https://github.com/hedging8563/tokenlab-mcp-server متاح للجمهور. وهو يكشف عن أربع أدوات ذات صلة بالاستكشاف:

• list_models — تعداد ما هو متاح، مع إمكانية التصفية.
• get_model — سحب تفاصيل حول معرف نموذج معين.
• get_model_pricing — سحب التسعير الحالي لنموذج معين.
• get_api_overview — المكافئ الأصلي لـ MCP لقراءة llms.txt.

القيد المهم: هذا الخادم للقراءة فقط. فهو لا يستدعي واجهات برمجة تطبيقات الاستدلال المدفوعة نيابة عنك، ولا يقوم بعمل وكيل لطلبات الإنشاء. إنه يجيب على أسئلة حول النماذج، والتسعير، وشكل الـ API. إذا كان وكيلك يحتاج فعلياً إلى تشغيل الاستدلال، فإنه لا يزال يمر عبر الـ API العادي لـ TokenLab باستخدام مفتاحك الخاص — خادم MCP هو طبقة استكشاف، وليس طبقة تنفيذ. الخلط بين الاثنين خطأ شائع يستحق التجنب بشكل صريح في أي توجيه وكيل أو ملف مهارة تكتبه.

مثال استكشاف TokenLab MCP

تكشف TokenLab عن خادم بروتوكول سياق النموذج (MCP) للقراءة فقط والذي يسمح لوكلاء البرمجة باكتشاف النماذج المتاحة والتسعير دون إجراء أي استدلال. يوفر خادم MCP أربع أدوات:

• list_models — سرد النماذج المتاحة، مع إمكانية التصفية حسب recommended_for (مثل image، video، embedding، rerank، translation)
• get_model — استرجاع تفاصيل لنموذج معين
• get_model_pricing — استرجاع معلومات التسعير لنموذج معين
• get_api_overview — استرجاع ملخص لـ TokenLab API

مثال: سرد النماذج عبر MCP

{
  "tool": "list_models",
  "arguments": {}
}

مثال: تصفية النماذج حسب الاستخدام الموصى به

{
  "tool": "list_models",
  "arguments": {
    "recommended_for": "image"
  }
}

إذا كنت تفضل الاستعلام عن الـ API مباشرة بدلاً من المرور عبر MCP، فإن استدعاءات REST المكافئة هي:

# سرد جميع النماذج
curl https://api.tokenlab.sh/v1/models \
  -H "Authorization: Bearer sk-KEY"

# سرد النماذج الموصى بها لمهام الصور
curl "https://api.tokenlab.sh/v1/models?recommended_for=image" \
  -H "Authorization: Bearer sk-KEY"

لاحظ أن خادم MCP للقراءة فقط بدقة — فهو مخصص للاستكشاف (سرد النماذج، فحص التسعير، ومراجعة قدرات الـ API) ولا يقوم بأي استدلال بنفسه.

للحصول على تعليمات الإعداد وتفاصيل التكامل، راجع:

• خادم TokenLab MCP
• مهارة وكيل البرمجة

مستودع المهارات

https://github.com/hedging8563/tokenlab-skills يحزم نمط الاستكشاف هذا في شيء يمكن لإطار عمل وكيل البرمجة تحميله مباشرة — تعريف مهارة يخبر الوكيل "اقرأ هذا قبل أن تكتب كود تكامل TokenLab"، بدلاً من الاعتماد على الوكيل ليقرر بشكل مستقل التحقق.

سير عمل الوكيل الموصى به

تصف الوثائق العامة تسلسلاً محدداً، وهو صامد بشكل جيد في الممارسة العملية:

1. قبل ترميز أي اسم نموذج بشكل ثابت، استدعِ /v1/models أو اقرأ llms.txt للتأكد من أن المعرف موجود بالفعل في الوقت الحالي.
2. للمهام غير المتعلقة بالدردشة — الصور، الفيديو، الموسيقى، 3D، TTS، STT، التضمين، إعادة الترتيب، الترجمة — قم بالتصفية باستخدام /v1/models?recommended_for=<task> بدلاً من افتراض أن نموذجاً موجهاً للدردشة يتعامل مع المهمة، أو تخمين اسم نموذج من الذاكرة.
3. قبل إعادة محاولة طلب فاشل غير متعلق بالدردشة، اقرأ /v1/models/:model و /v1/models/:model/pricing. غالباً ما سيفشل الطلب الفاشل ضد نموذج ذي وسائط خاطئة مرة أخرى عند إعادة المحاولة بنفس المدخلات؛ التحقق من الوسائط الفعلية للنموذج وتسعيره أولاً يوفر حلقة إعادة محاولة.

هذا التسلسل مهم لأنه يعالج مسبقاً نمطي الفشل الأكثر شيوعاً: معرف النموذج الخاطئ، وعائلة النموذج الخاطئة للمهمة.

قائمة مرجعية عملية لربط هذا بوكيل

الخطوة	ما يجب التحقق منه	أين
1	هل لا يزال معرف النموذج هذا يعمل؟	/v1/models أو llms.txt
2	هل هذه هي عائلة النماذج الصحيحة للمهمة (دردشة مقابل صورة مقابل تضمين، إلخ)؟	/v1/models?recommended_for=<task>
3	ما هو تسعير المدخلات/المخرجات الحالي لهذا النموذج؟	/v1/models/:model/pricing أو get_model_pricing (MCP)
4	ما هي نافذة السياق والوسائط؟	/v1/models/:model أو get_model (MCP)
5	هل يوجد نموذج أحدث باسم مشابه حل محل هذا النموذج؟	catalog.json / latest.json
6	هل قرأ الوكيل llms.txt قبل إنشاء كود التكامل؟	تأكد في سجل استدعاء أداة الوكيل

إذا تخطى الوكيل الخطوتين 1 و 2، فإن كل ما يليه — عمليات إعادة المحاولة، معالجة الأخطاء، تقديرات التكلفة — مبني على افتراض بدلاً من حقيقة.

لماذا يهم هذا للمهام غير المتعلقة بالدردشة تحديداً

تحظى نماذج الدردشة بمعظم الاهتمام، ولكن عامل التصفية recommended_for موجود لأن المهام غير المتعلقة بالدردشة تفشل بطرق أقل وضوحاً. نموذج مبني لتوليد النص إلى نص يعيد استجابة مشوهة لطلب صورة لا يطرح دائماً خطأً نظيفاً وواضحاً بذاته. في بعض الأحيان يعيد فقط شيئاً لا يعرف الوكيل كيفية تحليله.

التصفية حسب recommended_for=image، وrecommended_for=video، وrecommended_for=embedding، وما إلى ذلك تضيق مجموعة المرشحين قبل أن يكتب الوكيل أي نص طلب. بالنظر إلى عدد إدخالات توليد الصور المميزة التي يمكن أن توجد في كتالوج النماذج في أي وقت — nano-banana-2 (Gemini 3.1 Flash Image)، وnano-banana-pro (Gemini 3 Pro Image)، وnano-banana-2-lite (Gemini 3.1 Flash Lite Image)، وopenai/gpt-image-2، وreve/reve-2.0، وmicrosoft/mai-image-2.5 — فإن تخمين أيهما هو "نموذج الصور" من الذاكرة هو بالضبط نمط الفشل الذي صُمم سير العمل هذا لمنعه. يحتوي توليد الفيديو على مجموعته الخاصة من النماذج الخاصة بالمهام (seedance، وveo-3، من بين أمور أخرى) ذات تسعير وأشكال وسائط مختلفة؛ ينطبق نفس منطق التصفية.

للحصول على التسعير الحالي الدقيق، وحدود السياق، والوسائط لأي نموذج محدد مذكور هنا، تحقق من كتالوج النماذج وصفحة التسعير مباشرة — هذا هو الهدف الكامل من عدم ترميزه بشكل ثابت في منشور مدونة أيضاً. إذا كنت تقيم نماذج لأعمال التطوير التي يقودها الوكلاء تحديداً، فراجع أفضل نماذج AI للبرمجة 2026.

ما لا يفعله هذا

الدقة هنا تهم بقدر سير العمل نفسه:

• خادم MCP لا ينفذ استدلالاً مدفوعاً. إنه يجيب على أسئلة الاستكشاف. لا يزال تشغيل طلب إنشاء فعلي يمر عبر الـ API القياسي باستخدام بيانات اعتمادك الخاصة.
• llms.txt وملفات مركز بيانات النماذج هي لقطات دورية، وليست اتصالاً مباشراً بقاعدة بيانات. توقيت التحديث ليس ثابتاً على جدول زمني صارم، لذا تعامل مع أي تاريخ في هذه الصفحات على أنه تقريبي. لأي شيء حساس للسعر أو حساس للسلامة، تظل نقطة نهاية التسعير وAPI لوحة التحكم هي مصدر الحقيقة في وقت الطلب.
• لا شيء من هذا يحل محل قراءة وثائق الـ API الكاملة للمصادقة، أو حدود المعدل، أو دلالات معالجة الأخطاء. تخبر واجهات الاستكشاف الوكيل بما هو موجود؛ فهي لا تحل محل وثائق التكامل حول كيفية استدعائها بشكل صحيح.

الأسئلة الشائعة

ما الذي يجب أن يقرأه الوكيل قبل اختيار نموذج TokenLab؟ اقرأ llms.txt (أو llms-full.txt لمزيد من التفاصيل) واستدعِ /v1/models قبل ترميز أي معرف نموذج بشكل ثابت. للمهام غير المتعلقة بالدردشة، قم بالتصفية باستخدام recommended_for بدلاً من تخمين اسم نموذج من الذاكرة.

هل يستدعي TokenLab MCP واجهات برمجة تطبيقات الاستدلال المدفوعة؟ لا. خادم TokenLab MCP العام للقراءة فقط. أدواته (list_models، وget_model، وget_model_pricing، وget_api_overview) تجيب على أسئلة الاستكشاف حول النماذج والتسعير. تمر استدعاءات الاستدلال الفعلية عبر الـ API القياسي باستخدام مفتاحك الخاص.

متى يجب على الوكيل استخدام recommended_for؟ كلما كانت المهمة ليست دردشة عادية — صور، فيديو، موسيقى، 3D، TTS، STT، تضمين، إعادة ترتيب، أو ترجمة. التصفية حسب المهمة تضيق قائمة النماذج إلى المتغيرات المبنية فعلياً لتلك الوسائط، بدلاً من افتراض أن نموذجاً موجهاً للدردشة سيتعامل معها.

كيف يقلل هذا من معرفات النماذج القديمة في الكود الذي تم إنشاؤه؟ من خلال جعل الاستكشاف الخطوة الأولى بدلاً من فكرة لاحقة. الوكيل الذي يقرأ llms.txt، ويتحقق من /v1/models، ويؤكد التسعير قبل كتابة الكود يعمل من لقطة حالية بدلاً من ذاكرة وقت التدريب التي قد تكون بالفعل أقدم بعدة أجيال من النماذج.

المصادر والحداثة

• TokenLab llms.txt — https://api.tokenlab.sh/llms.txt — تمت ملاحظته في 2026-07-09
• TokenLab llms-full.txt — https://api.tokenlab.sh/llms-full.txt — تمت ملاحظته في 2026-07-09
• وثائق خادم TokenLab MCP — https://docs.tokenlab.sh/integrations/tokenlab-mcp-server — تمت ملاحظته في 2026-07-09
• وثائق مهارة تكامل TokenLab API — https://docs.tokenlab.sh/integrations/coding-agent-skill — تمت ملاحظته في 2026-07-09
• مستودع خادم TokenLab MCP — https://github.com/hedging8563/tokenlab-mcp-server — تمت ملاحظته في 2026-07-09
• مستودع مهارات TokenLab — https://github.com/hedging8563/tokenlab-skills — تمت ملاحظته في 2026-07-09
• مركز بيانات نماذج TokenLab — https://tokenlab.sh/model-data/catalog.json، https://tokenlab.sh/model-data/latest.json، https://tokenlab.sh/model-data/summary.md — تمت ملاحظته في 2026-07-09

تعكس معرفات النماذج، والتسعير، وتفاصيل الوسائط في هذه المقالة لقطة تم التقاطها وقت الكتابة. يتم تحديث صفحات اللقطات مثل هذه وllms.txt بشكل دوري، ولكن ليس على إيقاع ثابت أو مضمون — لا تبنِ منطق إعادة المحاولة أو تقديرات التكلفة حول فاصل تحديث مفترض. تحقق من القيم الحالية مقابل صفحة التسعير وكتالوج النماذج قبل شحن كود التكامل. للحصول على نظرة أعمق حول كيفية هيكلة التسعير عبر عائلات النماذج، راجع تسعير Gemini API للمطورين.

الخطوات التالية مع TokenLab MCP

للبدء في استخدام TokenLab MCP لاستكشاف النماذج:

1. احصل على مفتاح API من لوحة تحكم TokenLab.
2. قم بتوصيل وكيلك باتباع دليل تكامل وكيل البرمجة.
3. تصفح الكتالوج مباشرة على tokenlab.sh/en/models لرؤية تغطية النماذج الحالية والبيانات الوصفية.
4. تحقق من التسعير للنماذج التي تخطط لاستخدامها على tokenlab.sh/en/pricing.

إذا كنت تقرر أي النماذج تناسب سير عملك، فراجع تحليلاتنا حول أفضل نماذج AI للبرمجة في 2026 وتسعير Gemini API للمطورين.

ضع في اعتبارك أن MCP هو مجرد طبقة استكشاف — فهو يكشف عن البيانات الوصفية للنموذج، والقدرات، والتسعير حتى يتمكن وكيلك من اتخاذ قرارات مستنيرة. لا تزال استدعاءات الاستدلال الفعلية تمر عبر الـ API القياسي لـ TokenLab باستخدام مفتاح API الخاص بك؛ لا يقوم MCP بتوجيه أو عمل وكيل للطلبات.