הוספת solvethree MCP ל-Cursor

1. 1.

   הגדרת משתני הסביבה

   הגדירו את SOLVETHREE_API_KEY למפתח ה-API של סביבת העבודה שלכם ואת SOLVETHREE_PROXY לפרוקסי שבו תשתמשו לפתרון ולשליחה. ודאו ששניהם זמינים לתהליך שמפעיל את Cursor. אל תכללו פרטי גישה מפורשים בתצורת פרויקט.

2. 2.

   בחרו את קובץ התצורה

   השתמשו ב-.cursor/mcp.json להגדרה ייעודית לפרויקט או ב-~/.cursor/mcp.json להגדרה ברמת המשתמש. רשומה בשם solvethree ברמת הפרויקט גוברת על רשומה גלובלית באותו שם.

3. 3.

   הוסיפו את רשומת השרת

   השתמשו בתצורה שלהלן. אם הקובץ כבר מכיל שרתים אחרים, הוסיפו את solvethree בתוך אובייקט mcpServers הקיים במקום להחליף את הקובץ.

{
  "mcpServers": {
    "solvethree": {
      "command": "npx",
      "args": [
        "--yes",
        "--package=https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz",
        "solvethree-mcp"
      ]
    }
  }
}

כך מופעל solvethree-mcp מהורדת ה-SDK הרשמית באמצעות npx. התצורה יורשת את הסביבה של Cursor; היא אינה תלויה בהצבת ערכי משתני סביבה בתוך ה-JSON.

צאו לחלוטין מ-Cursor ואז הפעילו אותו מחדש מתוך סביבה שמכילה את שני המשתנים. ייצוא משתנים במסוף אינו מעדכן ממשק גרפי שכבר פועל.

בדקו את כלי ה-MCP של Cursor ואת הפלט של MCP Logs. השרת חושף את solvethree_capabilities,‏ solvethree_create_recaptcha,‏ solvethree_create_kasada,‏ solvethree_create_tmpt ו-solvethree_get_task. קראו תחילה ל-solvethree_capabilities כדי לבדוק אילו פעולות זמינות.

השרת אינו עולה.

בדקו ב-MCP Logs את שגיאת האתחול.

כדאי לנסות: אם Cursor אינו מוצא את npx, ודאו שהוא זמין ב-PATH של Cursor והפעילו מחדש את Cursor.

השרת מדווח על משתני סביבה חסרים.

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

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

Cursor משתמש בתצורה לא צפויה.

חפשו רשומה של solvethree בשני קובצי התצורה.

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

למידע על ממשק התצורה של Cursor, עיינו בתיעוד ה-MCP הרשמי שלו.

1. 1.

   ודאו שפרופיל האתר פעיל

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

2. 2.

   קראו לכלי reCAPTCHA

   בקשו מ-Cursor לקרוא ל-solvethree_create_recaptcha עם site,‏ action ו-requestId ייחודי. site הוא שם המארח, לא כתובת URL של דף. ברירת המחדל של recaptchaType היא enterprise-v3;‏ waitMs הוא אופציונלי. הכלי קורא את הפרוקסי היחיד שלו מתוך SOLVETHREE_PROXY, לכן אל תוסיפו ארגומנט פרוקסי, type או url.

3. 3.

   עקבו אחר המשימה עד למצב סופי

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

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

עבודת שרת ה-MCP מסתיימת כשהמשימה מוכנה. על היישום שלכם לשלוח את טוקן ה-reCAPTCHA שהוחזר ליעד המיועד. השתמשו בזהות userAgent ו-secChUa שהוחזרה עם אותו פרוקסי שהוגדר לפתרון. החלפת פרוקסי או שילוב של זהות דפדפן לא קשורה עלולים לגרום לבקשה להיכשל.

אם אתם משתמשים בכלים האחרים, הקפידו להבחין בין סוגי הפתרונות: Kasada מחזיר אובייקט כותרות שיש להחיל יחד, ואילו TMPT מחזיר ערך גולמי של עוגיית tmpt. אף אחד מהם אינו טוקן reCAPTCHA.

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