Docker Hub MCP: اكتشف الصور أولاً ثم قرر إن كنت ستدير المستودعات برمز وصول

لمن يناسب

لمن يحتاج أن يقوم النموذج باكتشاف محتوى الصور عبر Docker Hub API، ثم يدير المستودعات بعد إرفاق رمز وصول شخصي. يناسب من ثبّت Docker محليًا ولديه Node.js 22+ ويقبل هذه المقدمة: الرمز اختياري، لكن ما إن تُرسل HUB_PAT_TOKEN عبر HTTP حتى يتمكن كل من يصل إلى تلك البوابة من إنشاء المستودعات وتعديلها بهوية ذلك الحساب. لا يناسب من يريد فقط تصفح الدليل على الويب، أو يخطط لكشف منفذ HTTP على الشبكة دون قراءة ملاحظات الأمان في الشيفرة المصدرية. الصفحة الرسمية: https://github.com/docker/hub-mcp

أول تجربة في 3 دقائق

اتبع مسارًا رسميًا واحدًا فقط: بعد البناء في جذر المستودع، ابدأ بالنقل الافتراضي stdio. في المرة الأولى لا تغيّره إلى http.

المتطلبات المسبقة: Docker مثبّت، إلى جانب Node.js 22+. رمز الوصول الشخصي اختياري؛ في أول تجربة لا تربط الرمز بنقل HTTP.

موضع التثبيت والتشغيل: افتح جذر المستودع الرسمي ونفّذ:

npm install
npm run build
npm start

النقل الافتراضي في الشيفرة هو stdio، ويُسمح أيضًا بـ npm start -- [--transport=http|stdio] [--port=3000] [--host=127.0.0.1]. في المرة الأولى أبقِ الافتراضي.

إجراء منخفض المخاطر: بعد أن يتصل عميل MCP بعملية stdio، نفّذ فقط استدعاءات في اتجاه اكتشاف المحتوى. المقتطف ذكر فقط intelligent content discovery و repository management دون أسماء أدوات أو معاملات محددة، لذلك لا تختلق أوامر استعلام. اعتمد الأدوات التي يسردها العميل، وفضّل الاسم الذي يبدو اكتشافًا/استعلامًا لا إنشاءً أو تعديلًا.

إشارة النجاح: يبقى npm start يعمل على stdio الافتراضي ويستطيع العميل سرد الأدوات، بدل أن يخرج فورًا بسبب غياب البناء أو نقص إصدار Node. إذا انتهت العملية فورًا، تحقق أولاً من Node.js 22+ ومن اكتمال npm run build.

حالات الاستخدام

الحالة الأولى: اكتشاف المحتوى العلني. يقابل عبارتي المصدر «interfaces with Docker Hub APIs» و«intelligent content discovery». على stdio الافتراضي ودون إلزام بالرمز، اطلب من العميل استدعاءً واحدًا من نوع الاكتشاف. الأدلة لا تذكر اسم الأداة ولا معاملات التصفية ولا حقول الإرجاع، لذا لا تؤكد إلا ما إذا وصل الاستدعاء إلى Docker Hub API وما إذا أعاد العميل نتيجة أو خطأ API واضحًا؛ لا تفترض وجود صيغة بحث معينة.

الحالة الثانية: إدارة المستودعات مع آثار جانبية. تنص الشيفرة على أن نقل http يستخدم HUB_PAT_TOKEN الخاص بالمشغّل في كل استدعاء أداة، وأن من يصل إلى بوابة HTTP تلك يمكنه creating and modifying repositories. إن وجب إدارة المستودعات، وفّر الرمز للعملية محليًا ثم شغّلها؛ مثال المصدر هو HUB_PAT_TOKEN=... npm start -- [--username=...]. بعد التأكد من أن العميل متصل بعمليتك أنت وأن HTTP ما زال مربوطًا فقط بـ 127.0.0.1، ابدأ إنشاءً أو تعديلًا. نقطة التحقق: يظهر التغيير المتوقع على المستودع المقابل في Docker Hub. الأدلة لا تسرد جدول معاملات أدوات إدارة المستودعات؛ الجزء الناقص يتوقف عند «القدرة على إنشاء/تعديل المستودعات».

حدود الاستخدام

HTTP يُربط افتراضيًا بـ 127.0.0.1 ويتطلب مصادقة؛ تطلب الشيفرة قراءة Securing the HTTP transport قبل الكشف على الشبكة. لا تعامل HTTP غير المحصّن كمدخل مشترك.

ما إن يلمس شخص آخر HTTP الحامل لرمز المشغّل حتى يتمكن من إنشاء المستودعات وتعديلها بهوية Docker Hub تلك. تنبيه القراءة فقط لا يعني صفر مخاطر: العملية ستصل إلى Docker Hub API وستتصرف وفق الرمز الذي وفّرته.

الرمز اختياري في المتطلبات المسبقة، لكن المقتطف لا يوضح أي محتوى خاص يظهر دون مصادقة؛ لا تفترض أنك ستقرأ المستودعات الخاصة حتمًا.

الأدلة لا تعطي قائمة عملاء ولا جردًا كاملاً لأدوات MCP؛ لا تُكمل الأوامر من إضافات Hub أخرى. يلزم Docker و Node.js 22+؛ إن نقص أحدهما فلا تنتقل إلى طريقة تثبيت لم تظهر في المقتطف.