תיקון שרת MCP שלא מצליח לפעול או לפתור משימה

הריצו את תוכנית ההפעלה שסופקה במסוף במחשב שעליו פועל מארח MCP שלכם. לשחזור מבוקר, השתמשו ב־Node.js 22 וב־npx המצורף אליו; ודאו שלא נעשה שימוש בתוכנית הפעלה ישנה יותר שהותקנה בנפרד.

node --version
npx --yes --package=https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz solvethree-mcp
# The process waits for JSON-RPC on stdin. Silence is not a failed startup.
# Use the MCP host to initialize and list tools. Press Ctrl-C to stop this check.
# Never paste an API key or proxy password into troubleshooting logs.

תהליך שנשאר פתוח בלי להדפיס דבר לא בהכרח נתקע. זהו שרת stdio מקומי: הוא ממתין להודעות MCP JSON-RPC ב־stdin. השתמשו במארח MCP כדי לאתחל את החיבור ולהציג את רשימת הכלים; הרצת קובץ ההפעלה לבדו אינה מבצעת את לחיצת היד הזו.

אם הוא מסתיים, קראו תחילה את שגיאת ההפעלה. שגיאה של קובץ הפעלה שלא נמצא מצביעה על ההתקנה או על PATH; שגיאה בהורדת חבילה מתרחשת לפני פתרון המשימה. אף אחת מהן אינה מעידה על מפתח API, פרוקסי או פרופיל אתר שגויים.

רשמו את solvethree כשרת stdio מקומי, ולא כנקודת קצה מרוחקת של HTTP. המארח צריך להריץ את npx עם הארגומנטים שמוצגים בדוגמת תוכנית ההפעלה. אין נקודת קצה מתארחת של MCP.

המארח לא מצליח למצוא את npx.

השוו את PATH של המארח ל־PATH של המסוף שלכם. ייתכן שיישום שולחני לא יורש את הגדרות המעטפת שלכם.

כדאי לנסות: הפכו את התיקייה שמכילה את npx לזמינה למארח, או הגדירו את הנתיב המוחלט לאותו קובץ הפעלה שעבד מקומית.

המארח מריץ גרסה אחרת של Node.js או npx.

בדקו אילו קובצי הפעלה המארח מאתר, ולא רק באילו גרסאות המסוף שלכם משתמש.

כדאי לנסות: הפנו את המארח להתקנה שנבדקה. הפעילו מחדש את המארח לאחר שינוי הסביבה שלו.

האתחול מדווח על JSON פגום או על פלט לא צפוי.

חפשו כרזות פתיחה של המעטפת, הודעות של סקריפט עוטף או הדפסות ניפוי שגיאות שנכתבות ל־stdout.

כדאי לנסות: שמרו את stdout לשימוש בלעדי של MCP JSON-RPC. שלחו פלט אבחון ל־stderr, שם המארח יכול לאסוף אותו בלי להתייחס אליו כתעבורת פרוטוקול.

המארח מפסיק להמתין במהלך ההפעלה.

בדקו את לוג ההפעלה והבחינו בין הפעלה איטית לבין תהליך שכבר הסתיים.

כדאי לנסות: בתצורה בסגנון Codex, השתמשו בערך המתועד 60 עבור startup_timeout_sec. המתנה ארוכה יותר לא תתקן קובץ הפעלה חסר או שגיאת הפעלה מפורשת.

המארח מדווח שכלי של solvethree אינו רשום.

ודאו שהשרת אותחל ובדקו את הכלים שהוחזרו בתהליך הגילוי.

כדאי לנסות: תקנו את רישום השרת או התחברו מחדש ובצעו שוב גילוי כלים. כלי חסר אינו שגיאת אימות API או ניסיון פתרון שנכשל.

השרת חושף את solvethree_capabilities, את solvethree_create_recaptcha, את solvethree_create_kasada, את solvethree_create_tmpt ואת solvethree_get_task. אם הגילוי מצליח אבל המארח לא יכול לקרוא לאחד מהשמות האלה, פתרו את אי־ההתאמה לפני שליחת בקשות למשימות.

1. 1.

   בדיקת הסביבה של תהליך המארח

   ספקו את SOLVETHREE_API_KEY ואת SOLVETHREE_PROXY דרך סביבת המארח. ייצוא משתנה במסוף נפרד לא מבטיח שהמארח יכול לקרוא אותו. בתצורה בסגנון Codex, הרשימה env_vars חייבת לכלול את שני השמות; רשימת ההעברה הזו לא מספקת את הערכים שלהם. בדקו שהם קיימים בלי להדפיס את המפתח או את פרטי הגישה לפרוקסי.

2. 2.

   בדקו את הפרוקסי במקום שבו הכלי קורא אותו בפועל

   solvethree_create_recaptcha קורא את הפרוקסי היחיד שלו מתוך SOLVETHREE_PROXY. אל תנסו לתקן ערך סביבה חסר באמצעות הוספת ארגומנט proxy לכלי הזה. כתובת הפרוקסי צריכה להשתמש ב-HTTP או ב-HTTPS ולא לכלול נתיב, שאילתה או מקטע.

3. 3.

   בדקו את פרופיל האתר של reCAPTCHA

   לסביבת העבודה המזוהה באמצעות מפתח ה-API צריך להיות פרופיל פעיל עבור האתר וסוג ה-reCAPTCHA המבוקשים. בדקו גם את פעולת הלכידה: פרופיל כללי אחד לשם מארח לא בהכרח נותן מענה לכל פעולה. ציון site ו-action במשימה לא יוצר פרופיל. השתמשו בדף פרופילי האתרים במסוף או במדריך להגדרת פרופיל כדי לפתור זאת.

4. 4.

   בדקו את הקלט של הכלי

   עבור solvethree_create_recaptcha, ספקו את site כשם מארח, וכן action ו-requestId. השדה recaptchaType הוא אופציונלי וברירת המחדל שלו היא enterprise-v3. אל תחליפו את site בכתובת של דף ואל תוסיפו לכלי הזה את סוגי המשימות האחרים של ה-API.

גילוי יכולות לא בודק אימות או גישה לפרוקסי. שגיאת אימות או אימות תקינות של בקשה לאחר קריאה מוצלחת ליכולות קשורה לבקשת הפתרון, לא למפעיל. טפלו בתגובות HTTP שאינן מציינות הצלחה לפני שתתייחסו לתגובה כאל נתוני משימה מוצלחת.

חריגה מהזמן הקצוב במארח אינה מצב של משימה. תצורה בסגנון Codex משתמשת ב-tool_timeout_sec של 100, אבל אובדן התגובה עדיין לא מוכיח שיצירת המשימה נכשלה. כל כלי יצירה דורש requestId ויוצר לכל היותר משימה אחת.

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

כשהמשימה מוכנה, שלחו את הפתרון שלה עם זהות הדפדפן שהוחזרה ועם הפרוקסי שהצליח. אם האתר דוחה לאחר מכן את הבקשה, בדקו את השליחה הזו ולא את הפעלת ה-MCP. שמרו על פרטיות נתוני הפתרון: מארח ה-MCP מקבל אותם.