שימוש בתוצאת CAPTCHA מ-MCP בסוכן דפדפן

1. 1.

   הגדירו את שרת ה-MCP המקומי

   פעלו לפי הוראות ההגדרה של MCP כדי להפעיל את solvethree-mcp באמצעות npx. זהו שרת stdio מקומי, לא נקודת קצה מתארחת. ספקו את SOLVETHREE_API_KEY ואת SOLVETHREE_PROXY דרך סביבת המארח; אל תכניסו פרטי גישה להנחיה של הסוכן.

2. 2.

   בדקו את הכלים הזמינים ואת פרופיל האתר

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

3. 3.

   ודאו שהדפדפן יכול לשלוח את הבקשה התואמת

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

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

השתמשו בהנחיה הזו לאחר הגדרת שרת ה-MCP והדפדפן. ספקו את שם מארח היעד ואת פעולת הביצוע מתוך בקשת היישום. ברירת המחדל של solvethree_create_recaptcha היא Enterprise v3; הארגומנטים הנדרשים שלו הם site,‏ action ו-requestId.

Use the already-configured solvethree MCP server for one reCAPTCHA Enterprise task.
The target hostname must have an active workspace profile before creation.
1. Keep one requestId for this logical task. Ask before starting another paid task.
2. Call solvethree_create_recaptcha with site, action and that requestId.
   The server reads its target proxy from SOLVETHREE_PROXY.
3. Save the returned id. Call solvethree_get_task for that id while pending/solving,
   stopping at ready, failed or the agreed deadline. Never poll by creating again.
4. If ready, submit solution.token using the application’s actual token parameter.
   Use the returned userAgent/secChUa and the same pinned proxy in the browser.
   Keep the application’s cookies, CSRF fields and session requirements.
5. Read the application response. Report task ID and outcome, not secret solution data.
If the browser tool cannot configure that proxy and identity, stop and explain the
missing capability instead of claiming it submitted an equivalent request.

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

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

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

צרו requestId אחד לכל משימה לוגית ושמרו אותו עם הקלט המקורי. עליו להכיל 1–64 אותיות ASCII, ספרות, קווים תחתונים או מקפים. אם היצירה חורגת מהזמן הקצוב לפני שקיבלתם id, חזרו על אותה בקשת יצירה עם אותו requestId ועם קלט ללא שינוי כדי לשחזר את המשימה הקיימת. אם כבר יש לכם את ה-id של המשימה, השתמשו ב-solvethree_get_task.

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

כל קריאת יצירה ב-MCP יוצרת לכל היותר משימה אחת, אך הדבר לא מגביל את הוצאות הסוכן. דרשו אישור לפני התחלת משימה לוגית נוספת. במקרה של כישלון סופי, בדקו את errorCode ואת error לפני שתחליטו אם יש הצדקה לבקשה מתוקנת; ניתן החזר על פתרונות שנכשלו. שגיאת בקשה היא בעיה נפרדת ממשימה שמצבה failed.