הרצת שרת ה-MCP של solvethree ב-Docker

מאת solvethree3 דקות קריאה

בנו אימג' מקומי מההורדה הרשמית של ה־SDK בעלת מספר הגרסה, ואז הגדירו את מארח MCP להפעיל אותו באמצעות Docker. השאירו את stdin פתוח באמצעות -i והשמיטו את -t: השרת מתקשר ב־JSON-RPC דרך stdio, ולא בפרוטוקול מסוף.

בדף הזה

בניית האימג' המקומי

שמרו זאת בשם Dockerfile. הקובץ מתקין את החבילה הרשמית על Node 22, עובר למשתמש node שאינו root, ומפעיל את solvethree-mcp כנקודת הכניסה של הקונטיינר. פקודות הבנייה וההרצה מופיעות בהמשך.

Dockerfile · שרת stdio מקומי
FROM node:22.23.4-alpine
RUN npm install --global https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz
USER node
ENTRYPOINT ["solvethree-mcp"]

# Build: docker build -t solvethree-mcp-local .
# Forward variables already set in the host; do not add their values to this file.
# Run: docker run --rm -i -e SOLVETHREE_API_KEY -e SOLVETHREE_PROXY solvethree-mcp-local

לפני ההרצה, הגדירו את SOLVETHREE_API_KEY למפתח ה־API של סביבת העבודה שלכם ואת SOLVETHREE_PROXY לפרוקסי שלכם, בסביבה שמפעילה את Docker. כל -e NAME מעביר משתנה קיים; הוא לא מספק ערך. אל תכללו פרטי גישה ב־Dockerfile או באימג'.

האימג' נבנה מקומית בשם solvethree-mcp-local; אין צורך בחשבון Docker Hub. הרצתו אינה יוצרת נקודת קצה מתארחת של MCP ואינה מוסיפה אוטומציה של דפדפן.

הגדרת מארח MCP להפעלת Docker

הגדירו שרת stdio במארח MCP שלכם. השתמשו ב־Docker כפקודה, ולא ב־solvethree-mcp: נקודת הכניסה של האימג' מפעילה את קובץ ההפעלה בתוך הקונטיינר.

הגדרות הפעלה במארח MCP
הגדרות הפעלה במארח MCP
הגדרהערך
פקודהdocker
ארגומנטים, לפי הסדרrun, --rm, -i, -e, SOLVETHREE_API_KEY, -e, SOLVETHREE_PROXY, solvethree-mcp-local

אל תוסיפו -t. המארח זקוק ל־stdin ול־stdout של הקונטיינר עבור JSON-RPC. האפשרות --rm מסירה את הקונטיינר כשהוא מסתיים.

שני משתני הסביבה חייבים להיות זמינים לתהליך של מארח MCP. הגדרתם במסוף לא תעזור למארח שהופעל במקום אחר, אלא אם הוא יורש אותם. אם המארח מגביל העברת משתני סביבה, אפשרו את שני השמות.

בתצורת TOML בסגנון Codex, השתמשו בטבלה mcp_servers.solvethree עם הפקודה והארגומנטים שלעיל. כללו את שני שמות המשתנים ב־env_vars, הגדירו את startup_timeout_sec ל־60 ואת tool_timeout_sec ל־100. ראו את תיעוד האינטגרציה עם MCP לפרטי חוזה הממשק הבסיסי של השרת.

בקשת משימה והעברת התוצאה

  1. 1.

    בדיקת הכלים הזמינים

    קראו ל־solvethree_capabilities לאחר ההתחברות. השרת חושף כלי פתרון ואחזור משימות; הוא לא מפעיל דפדפן ולא ממלא טפסים.

  2. 2.

    הכנת פרופיל reCAPTCHA

    עבור reCAPTCHA, הגדירו פרופיל פעיל בפרופילי אתרים לפני בקשת פתרון. התאימו את שם המארח, פעולת הלכידה וסוג reCAPTCHA; אל תניחו שפרופיל אחד של דומיין מכסה כל פעולה. שליחת משימה אינה יוצרת פרופיל. המדריך להגדרת פרופיל מסביר את דרישת הקדם הזו.

  3. 3.

    יצירת משימה לוגית אחת

    קראו ל־solvethree_create_recaptcha עם site, עם action ועם requestId; הפרמטרים recaptchaType ו־waitMs הם אופציונליים. הכלי קורא את הפרוקסי היחיד שלו מתוך SOLVETHREE_PROXY. כל קריאת יצירה יוצרת לכל היותר משימה אחת. אם היצירה חורגת ממגבלת הזמן, השתמשו שוב באותו מזהה בקשה עם קלטים ללא שינוי כדי לשחזר את המשימה הקיימת במקום ליצור משימה נוספת.

  4. 4.

    המתנה לתוצאה שניתן להשתמש בה

    אם המשימה בסטטוס pending או solving, אחזרו אותה באמצעות solvethree_get_task. רק ready מכיל פתרון שניתן להשתמש בו. בסטטוס failed, הפסיקו את התשאול ובדקו את errorCode ואת error לפני שתחליטו מה לשנות.

  5. 5.

    שליחה מתוך היישום שלכם

    עבור reCAPTCHA, שלחו את solution.token, ולא את מזהה המשימה. השתמשו בזהות שהוחזרה ב־userAgent וב־secChUa עם הפרוקסי שבאמצעותו הפתרון הצליח. משימה מוכנה מציינת שנוצר פתרון, ולא שהיעד קיבל את בקשת היישום שלכם.

מארח MCP מקבל נתוני פתרון פרטיים. אל תכללו את התוצאות האלה בלוגים משותפים; היישום שלכם נשאר אחראי לשליחתן ליעד המיועד.

הפעלת המשימה הראשונה שלך.

התחילו עם $5 בקרדיט לסביבת העבודה.

יצירת סביבת עבודה
הרצת שרת ה-MCP של solvethree ב-Docker · solvethree