llms.txt للدومينات: واجهة API يقدر أي وكيل ذكاء اصطناعي يقراها

كل مُسجِّل عنده واجهة API عنده وثائق في مكان ما: موقع docs، أو صفحة مرجعية، أو يمكن مواصفة OpenAPI ورا صفحة تسجيل دخول. ده كان كفاية لمدة عقدين، لأن القارئ كان مطوّر بشري يقدر يضغط هنا وهناك ويتخطّى زحمة التنقّل عشان يوصل للفقرة اللي تهمه. وكيل ذكاء اصطناعي بيقرأ الموقع نفسه وقت الاستدلال ما عندوش الرفاهية دي: ميزانية سياق محدودة، ومش هيستحمل بوابة وثائق معمولة بـ JavaScript، ومحاولة واحدة عشان يفهم الـ API بتعمل إيه قبل ما يسيبها أو يهلوس بنقطة نهاية مش موجودة.

llms.txt هو الحل للمشكلة دي، وNamefi بتنشر واحداً على namefi.io/llms.txt. المقال ده بيشرح الاصطلاح ده إيه، وليه موجود، وملفنا فيه إيه جزءاً جزءاً، وفين بيتوقف عن قصد، وإزاي بيشتغل جنب بروتوكول سياق النموذج (MCP) بدل ما ينافسه. وهو كمان، عن قصد، مثال على الحاجة اللي بيشرحها: مزوّد API عام بيشرح ملف اكتشافه المقروء آلياً بلغة بسيطة.

ليه الوكلاء ما ينفعش يزحفوا على موقع الوثائق وخلاص

المنطق وراء llms.txt مش تخمين — هو مذكور بشكل مباشر في المقترح. الشرح الأصلي لجيريمي هوارد بيفتتح بالقيد اللي خلّى الفكرة ضرورية: "Large language models increasingly rely on website information, but face a critical limitation: context windows are too small to handle most websites in their entirety. Converting complex HTML pages with navigation, ads, and JavaScript into LLM-friendly plain text is both difficult and imprecise."

هنا مشكلتين فوق بعض. موقع وثائق حقيقي — قوائم تنقّل، وسجل تغييرات، ونص تسويقي، وبانر ملفات تعريف الارتباط — معظمه دوشة مقارنة بالكم فقرة اللي الوكيل محتاجها لمهمة واحدة. وكثير من الدوشة دي ورا JavaScript ما بيتنفذش في طلب headless عادي، فالحاجة اللي عميل HTTP بتاع الوكيل بيشوفها مش حتى الصفحة اللي الإنسان بيشوفها. llms.txt بيتجاوز المشكلتين: ملف Markdown واحد نصه عادي، معمول عشان يتقرا كله بدل ما يتزحف عليه ويتلخّص.

تشبيه robots.txt، وفين التشبيه ما بيكملش

المقارنة مع robots.txt أسرع طريقة لفهم مكان llms.txt لو أنت عارف بنية الويب، وهي مقارنة عادلة لحد معين. robots.txt موجود عشان يدي تعليمات لزواحف الويب — على وصف الموقع نفسه: "Web site owners use the /robots.txt file to give instructions about their site to web robots; this is called The Robots Exclusion Protocol." الملفين موجودين في مسار جذر متوقع، والاتنين نص عادي، والاتنين بيخاطبوا قرّاء آليين مش بشر.

التشبيه بيقف عند النية. robots.txt تقريباً كله تعليمات سلبية — Disallow: /some-path بتقول للزاحف إيه اللي ما يلمسوش. llms.txt إيجابي: ده الموقع إيه، ودي الأجزاء اللي تستاهل القراءة. هو مش سياج بقدر ما هو فهرس محتويات لقارئ ما يقدرش يفتح الكتاب كله. الاتنين مكمّلين لبعض، وموقع Namefi بيشغّل الاتنين.

المواصفة بتطلب إيه بالضبط

llms.txt مش مساحة كتابة حرّة؛ المقترح بيعرّف بنية Markdown محددة بالترتيب: علامة byte-order اختيارية، ثم H1 إلزامي باسم الموقع، وملخص على هيئة blockquote، وصفر أو أكثر من أقسام التفاصيل بلا عنوان، وصفر أو أكثر من أقسام «قائمة ملفات» مفصولة بـ H2، روابطها بالشكل [name](url): notes. عنوان H2 واحد له معنى خاص: قسم اسمه Optional بيقول إن «الروابط هنا ممكن تتخطاها لو محتاج سياق أقصر». ملف Namefi بيستخدم العنوان ده بالضبط وبيعمل اللي المواصفة بتوصفه.

جولة داخل namefi.io/llms.txt

ده الملف الحي، مشروح جزءاً جزءاً — إيه الموجود فعلاً فيه، منقول بالنص، وليه كل جزء متصمم بالشكل ده لوكيل بيقرأه لأول مرة.

الملف بيختتم بإشارة إلى namefi.io/llms-full.txt، وهو نفس المحتوى مضمن في وثيقة واحدة، بما في ذلك مسارات دفع Web3 ودليل الوكيل الصادر اللذين يشير إليهما ملف الجذر فقط. التقسيمة دي بتعكس نمط المستويين في المواصفة نفسها: خلّي نقطة الدخول قصيرة بما يكفي عشان تدخل براحة في السياق، وسيب الوكيل اللي محتاج أكثر يتبع رابط واحد.

الملفات المصاحبة: Web3 واكتشاف MCP

ملف الجذر بيربط بملفات شقيقة لأجزاء من الـ API ما تنفعش تكون في نقطة دخول عامة. namefi.io/web3/llms.txt بيوثق مسارات دفع يحتاجها وكيل ماسك محفظة بدل مفتاح API: مسار x402 حيث GET /x402/domain/{domainName} بيرجع 402 Payment Required مع السعر إلى أن يُرفق هيدر X-PAYMENT موقّع، ونسخة challenge-response من MPP (Machine Payable Protocol) موقعة عبر CLI اسمه mppx، ومسار توقيع EIP-712 يدوي يغطي محافظ العقود الذكية. الملف بيقول صراحة إن تسجيل x402 لا يحتاج "No Namefi account or EIP-712 signing required — the buyer's wallet signs an EIP-3009 transferWithAuthorization." الوكيل اللي محتاج مفتاح API فقط مش مضطر يحمّل أي حاجة من ده.

جانب MCP له ملف اكتشاف خاص به، منفصل تماماً عن llms.txt: namefi.io/.well-known/mcp/servers.json، وهو واصف JSON صغير بدل Markdown:

{
  "servers": [
    {
      "name": "namefi-api",
      "transport": "streamable-http",
      "url": "https://api.namefi.io/mcp",
      "authentication": {
        "type": "apiKey",
        "in": "header",
        "name": "x-api-key"
      },
      "documentation": "https://namefi.io/llms.txt"
    }
  ]
}

الواصف ده عايش تحت .well-known/، وهو نفس الاصطلاح اللي بيستخدمه /.well-known/security.txt لبيانات وصفية قابلة للاكتشاف آلياً — شقيق أضيق وبنوع JSON لطريقة Markdown النثرية في llms.txt. آخر حقل فيه بيرجع يشاور على llms.txt، فوكيل يلاقي خادم MCP الأول لسه عنده طريق للشرح النصي العادي لأدوات الخادم دي بتعمل إيه.

إيه الموجود وإيه المتروك، وليه

في شوية اختيارات شكلها مقصود. تقريباً كل عملية مكتوبة كأمر curl قابل للتشغيل بدل فقرة بتوصف شكل الطلب — الملف مكتوب لحاجة بتنفّذ كود، مش لحاجة بتكتب ملخصاً عنه. ملف الجذر بيشير للخارج بدل ما يضمّن كل شيء، وllms-full.txt بيضمّن اللي بيكتفي بالإشارة إليه — تطبيق حرفي لنمط إدارة الحجم في المواصفة. قسم ## Optional بيربط مواصفة OpenAPI 3 كاملة جنب Markdown، فالأداة اللي محتاجة schema مكتوباً بأنواع صارمة تلاقيه من غير ما تزحم القراءة الأولى. ودفع المحفظة — x402 وMPP وEIP-712 — في ملف لوحده، فمصادقة مفتاح API وتسجيل الدومين يبقوا أول حاجتين أي وكيل يقراهم.

llms.txt وMCP: اكتشاف مقابل اتصال

المهم إننا نكون دقيقين في دور كل واحد. llms.txt وثيقة — الوكيل بيجلبها مرة واحدة وبيعرف الـ API بتعمل إيه وفين الموارد الأعمق؛ هي نص ساكن لحد ما حاجة تتصرف بناءً على اللي مكتوب فيه. MCP، حسب وصف البروتوكول نفسه، هو "an open-source standard for connecting AI applications to external systems" — جلسة حية العميل بيفتحها مع خادم، يسرد من خلالها أدوات قابلة للاستدعاء ويشغّلها.

ملف Namefi بيورّي العلاقة دي مباشرة: llms.txt بيقول للوكيل إن فيه خادم MCP على api.namefi.io/mcp وبيسيبه مع أمر claude mcp add عشان يتصل. اقرا الملف، اعرف إن فيه واجهة أدوات حية، اتصل، ونفّذ. وكيل يتخطى لـ MCP على طول يقدر برضه يلاقي الخادم عبر .well-known/mcp/servers.json — لكن حقل documentation في الواصف ده بيرجع لـ llms.txt، فالاتنين نادراً ما بيشتغلوا في عزلة تامة.

إرشادات لبقية مزوّدي API

نشر llms.txt شغال لا يتطلب إعادة بناء الوثائق:

1. حط H1 والملخص وأسرع طريقة اتصال في البداية — وكيل بسياق صغير ممكن ما يقراش بعد أول كام سطر.
2. ورّي طلبات قابلة للتشغيل، مش كلام عن schema. أمر curl بأسماء حقول حقيقية أحسن من فقرة بتشرح JSON body.
3. قسّم حسب الحجم، مش حسب هيكل الفريق. ملف جذر قصير مع توسعة أطول، وملفات منفصلة لحاجات زي الدفعات، بيخلّي المسار الشائع قصيراً.
4. وثّق حالات الفشل الفعلية، مش أكواد الحالة فقط — معرفة ليه الطلب بيرجع 401 بدل 403 أهم من الأرقام نفسها.
5. استخدم عنوان ## Optional لأي حاجة قابلة للتخطي، التزاماً باصطلاح المواصفة نفسها.
6. انشر واصف اكتشاف MCP جنب llms.txt لو بتشغّل خادم MCP — واحد بيجاوب «إيه ده؟»، والتاني «أتصل إزاي؟».

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

ما هو llms.txt؟

هو اصطلاح مقترح — مش معياراً رسمياً من IETF أو W3C — لنشر ملف Markdown نصي عادي عند جذر الموقع يشرح لوكيل ذكاء اصطناعي الموقع أو الـ API دي إيه وفين يلاقي تفاصيل أكثر. بيحدد ترتيباً معيناً: عنوان H1، وملخص blockquote، وفقرات تفصيل اختيارية، وقوائم روابط مفصولة بعناوين H2، مع احتفاظ عنوان "Optional" للروابط اللي ينفع تتخطى.

إيه الفرق بين llms.txt وrobots.txt؟

robots.txt تعليمات سلبية لزواحف الويب — إيه اللي ما تفهرسوش — ضمن Robots Exclusion Protocol. llms.txt إيجابي — الموقع إيه وإيه اللي يستاهل القراءة. بيخدموا قرّاء آليين مختلفين وعادة موجودين مع بعض.

هل llms.txt بيستبدل MCP؟

لا. llms.txt وثيقة الوكيل بيقراها مرة عشان يفهم الـ API بتعمل إيه؛ MCP اتصال بروتوكول حي بيفتحه العميل عشان يستدعي عمليات الـ API فعلاً. Namefi بتنشر الاتنين، وllms.txt هو اللي بيقول للوكيل من البداية إن خادم MCP موجود.

إيه الموجود في ملف llms.txt بتاع Namefi؟

رابط الأساس، وإشارة لخادم MCP، وقسم مصادقة بمفتاح API، ومسار تسجيل دومين من ثلاث خطوات مع أمثلة curl قابلة للتشغيل، وجدول نقاط نهاية لإدارة سجلات DNS، ونقاط نهاية لضبط الدومين، وقسم لحل المشاكل، وقسم "Optional" فيه روابط إلى SDK ومواصفة OpenAPI وملفات مصاحبة لدفعات المحفظة ومسارات العمل الصادرة.

ينفع أقرا llms.txt بنفسي من غير وكيل ذكاء اصطناعي؟

أيوه — هو Markdown نصي عادي، سهل القراءة للإنسان وللنموذج. namefi.io/llms.txt بيتقرا كمرجع API سريع ومكثف؛ والوضوح نفسه اللي بيسهّل على الإنسان يتصفحه بيسهّل على النموذج يحلله صح.

المصادر والقراءة الإضافية

• llmstxt.org — ملف /llms.txt: الخلفية والمقترح ومواصفة التنسيق
• robotstxt.org — نبذة عن /robots.txt: "In a nutshell"
• modelcontextprotocol.io — ما هو بروتوكول سياق النموذج (MCP)؟
• Namefi — namefi.io/llms.txt (المصدر الأساسي لكل مقطع مشروح في هذا المقال)
• Namefi — namefi.io/web3/llms.txt (مسارات دفع المحفظة x402 وMPP وEIP-712)
• Namefi — namefi.io/.well-known/mcp/servers.json (واصف اكتشاف MCP)
• Namefi — namefi.io/llms-full.txt (نسخة بملف واحد تدمج ملفي Web3 والوكيل الصادر)
• IETF — RFC 8615، معرّفات الموارد الموحدة المعروفة مسبقاً (اصطلاح .well-known/)

اقرأ الملف بنفسك

أسرع طريقة تفهم بها llms.txt هي إنك تفتح واحداً. namefi.io/llms.txt متاح للعامة، من غير مصادقة، وقصير كفاية تقراه في الوقت اللي أخذته في قراءة المقال ده — وهو نفس الملف اللي أي وكيل ذكاء اصطناعي بيتصل بـ Namefi بيقراه الأول. لو عايز تعرف أدوات MCP وراه بتعمل إيه فعلاً، راجع خادم Namefi MCP: أدوات دومينات لوكلاء الذكاء الاصطناعي؛ ولو عايز تتصل من محرر، راجع دليل MCP السريع؛ ولو عايز تشوف وكيلاً ينفّذ المسار كله، راجع إزاي تسجّل دومين باستخدام وكيل الذكاء الاصطناعي على Namefi.