WebMCP: שכבת הבקרה החסרה בין Agentic AI לאוטומציית בדיקות דטרמיניסטית

משבר שכבת הבקרה

בשנתיים האחרונות תעשיית התוכנה ואוטומציית הבדיקות נלחמה במלחמה הלא נכונה. ניסינו לגרום ל-AI planners הסתברותיים לדבר DOM שוטף.

האכלנו אותם ב-accessibility snapshots ענקיים. בנינו self-healing locators עמוסים ב-regex. שרפנו מיליוני טוקנים כדי ללמד LLMs “להבין” מרק <div> שלא נבנה לצריכה על ידי מכונה.

התוצאה צפויה: עלות מתפוצצת, latency מזנק, ו-governance הופך ל-best effort.

הבעיה אינה רק כלכלית. הבעיה היא Control.

כאשר נותנים ל-AI Agent לפעול על UI raw, מנתקים בין כוונה לביצוע.

• הכוונה: “הוסף subscription enterprise לעגלה ובצע checkout.”
• הביצוע: “מצא כפתור עם אייקון עגלה, קווה שאין modal של marketing מעליו, לחץ, חכה, נסה שוב אם animation איטי.”

הפער הזה הוא המקום שבו flakiness, latency וסיכוני אבטחה גדלים.

אנחנו מנסים לנהוג בפרארי של reasoning על דרך עפר של HTML.

החלק החסר באוטומציה מודרנית אינו selector טוב יותר. הוא Control Plane שמחבר כוונה אג’נטית לביצוע דטרמיניסטי בלי לטבוע ב-context ובלי להרחיב blast radius.

כאן נכנס WebMCP.

למה זה חשוב גם לעסק

לפני שמדברים על בדיקות, צריך לדבר על הישרדות עסקית.

אנחנו מתקרבים לעידן של Autonomous Commerce. סוכנים כמו ChatGPT, Claude או copilots ארגוניים יבצעו פעולות בשם משתמשים: “הזמן לי טיסה”, “שדרג לי את מסד הנתונים”, “קנה רישיון enterprise”.

דמיינו לקוח enterprise שמאשר ל-agent לרכוש upgrade של 50,000 דולר. ה-agent נכנס לעמוד billing. בדיוק באותו רגע צוות marketing מפעיל A/B test עם modal חדש.

ה-agent, שמסתמך על DOM ו-vision, לא מוצא את “Confirm Purchase”. הוא מנסה ללחוץ ברקע, מזייף פתרון, נכשל, וה-session מסתיים.

התוצאה: עסקה של 50,000 דולר אבדה בגלל pop-up.

אם חברות יסתמכו על AI שקורא HTML raw, כל שינוי UI יהפוך לסיכון revenue. כדי לאפשר commerce אג’נטי, המוצר חייב לחשוף interface מובנה ודטרמיניסטי.

ופה נמצא ה-authority arbitrage של Test Architect: אותו WebMCP שהמוצר יטמיע כדי לאפשר הכנסות אג’נטיות, יהפוך גם לתשתית של אוטומציית בדיקות יציבה במיוחד.

מה WebMCP באמת עושה

WebMCP מוצע כסטנדרט web שמאפשר לאתרים לחשוף כלים מובנים ל-browser agents. במקום שה-agent יסרוק DOM כדי להבין מה אפשר לעשות, האתר מצהיר על capabilities.

הנקודה הארכיטקטונית החשובה:

ה”שרת” יכול להיות העמוד עצמו.

במקום לחפש כפתור Login, הדפדפן חושף דרך navigator.modelContext כלי בשם loginAsUser, seedTestUser, simulateBillingFailure או provisionTenant.

זו דלת זהב ללוגיקה של האפליקציה. לא דרך CSS, לא דרך XPath, לא דרך accessibility snapshot ענק. דרך contract מוגדר.

התפתחות control surfaces

אנחנו עוברים מעולם של ניחוש לעולם של הצהרה.

המהלך המרכזי הוא להזיז כוונה upstream:

• DOM מכריח agent להסיק כוונה מתוך presentation.
• CLI מוציא artifacts כבדים מה-context.
• WebMCP גורם למוצר להכריז מה הוא מסוגל לעשות.

המוצר הופך ל-testing API, כי ההתנהגויות נחשפות כ-toolset מוגבל ולא נשלפות בכוח מה-UI.

ארכיטקטורת ארבע השכבות

כדי להשתמש ב-WebMCP נכון, צריך לחשוב על אוטומציה כ-control stack:

1. Reasoning Layer: ה-LLM בוחר אסטרטגיה וכלי.
2. Context Transport Layer: WebMCP מגדיר capabilities ו-schemas.
3. Execution Engine: Playwright, browser, traces, network, UI.
4. Governance Layer: Allure, Quality Gates, preview environments, policy.

השרשרת הזו מאפשרת accountability: מהכוונה של agent ועד הראיות שהשער משתמש בהן כדי לחסום או לאשר release.

איך זה נראה בקוד

ב-frontend אפשר לחשוף capability כך:

if (navigator.modelContext) {
  navigator.modelContext.registerTool({
    name: "simulateBillingFailure",
    description: "Triggers a simulated credit card decline state for the current session.",
    inputSchema: {
      type: "object",
      properties: {
        errorCode: { type: "string" }
      },
      required: ["errorCode"]
    },
    execute: async ({ errorCode }) => {
      return await window.billingService.forceDeclineState(errorCode);
    }
  });
}

ה-agent לא קורא HTML כדי לדמות כישלון billing. הוא שואל את הדפדפן:

“אילו כלים זמינים?”

הדפדפן עונה:

“יש כלי simulateBillingFailure שמקבל errorCode.”

ה-agent קורא לכלי. הביצוע לוגי, מהיר וחסין ל-A/B tests, רזולוציה, animation או שינוי CSS.

זה לא פשוט App Actions?

מי שמכיר Cypress עשוי לשאול: “זה לא כמו App Actions?”

כן ולא.

App Actions הם pattern פנימי, קשיח ומותאם לתסריט בדיקה. הסקריפט יודע בדיוק איפה נמצאת הפונקציה ומה להעביר לה.

WebMCP הוא capability contract סטנדרטי וגילוי דינמי.

ה-agent לא מכיר את ה-codebase. הוא קורא interface שמתאר את עצמו: שם, תיאור, schema. ההבדל:

• App Actions חושפים נתיבי ביצוע.
• WebMCP חושף capability surface.

זה דומה למה ש-OpenAPI עשה ל-REST: להפוך hooks פנימיים לחוזה machine-readable.

הדילמה של Playwright

אם WebMCP יכול להפעיל לוגיקה בצורה מושלמת, האם Playwright מיותר?

לא.

WebMCP הוא API. הוא מניע state. הוא לא מאמת UX.

אם משתמשים רק ב-WebMCP, עושים API testing בתוך הדפדפן. לא יודעים אם CSS נשבר, אם button מוסתר, או אם המשתמש באמת רואה success message.

הארכיטקטורה המנצחת היא Capability Testing Model:

• WebMCP עבור state driving.
• Playwright עבור UX verification.

לדוגמה:

test("checkout via WebMCP and Playwright", async ({ page }) => {
  await page.goto("/checkout");

  await page.evaluate(async () => {
    const client = await navigator.modelContext.createClient();
    await client.callTool("fillCheckoutDetails", {
      user: "sysadmin-1",
      paymentProfile: "visa-valid",
      shippingMethod: "express"
    });
  });

  await expect(page.getByRole("heading", { name: "Order Confirmed" })).toBeVisible();
  await expect(page.getByTestId("total-price")).toContainText("$120.00");
});

ה-UI נבדק כייצוג של capability, לא כמקום שבו בונים את capability מאפס בכל ריצה.

פצצת האבטחה

WebMCP מצמצם ambiguity, אבל משנה את צורת הסיכון.

כבר לא מדובר ב-”ה-agent לחץ על כפתור לא נכון”. עכשיו מדובר ב-”ה-agent קרא לכלי בעל כוח אמיתי”.

לכן חובה להגדיר:

• tool allowlists.
• environment scoping.
• הסרה מוחלטת של test-only tools מ-production.
• policy מחוץ למודל.
• human-in-the-loop לפעולות הרסניות.

Tool descriptions הם input לא מהימן. CI agents עלולים להחזיק secrets. tools יכולים להשתלב באופן מסוכן. זה לא נושא QA בלבד. זה נושא ארכיטקטורה ואבטחה.

מה משתנה בצוות

WebMCP אינו שדרוג tooling. הוא שינוי ארגוני.

• Frontend/Product Developers: אחראים גם ל-testability contract, לא רק UI.
• QA/SDETs: מפסיקים לצוד selectors והופכים ל-contract auditors.
• Security/DevSecOps: מגדירים tool policy ו-governance.

סיכום: עידן Capability Governance

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

אנחנו זזים מ-Selector Gates ל-Workflow Gates, ואז ל-Capability Gates. כאשר בדיקה נכשלת, השאלה כבר לא תהיה “האם locator נשבר?”, אלא “איזה contract הופר תחת תנאי pre-merge מבוקרים?”

עבור Test Architect זו קריאה לפעולה.

אל תחכו שהתעשייה תגרור אתכם לשם. התחילו לארכיטקט אפליקציות שחושפות חוזי testability.

Reasoning שייך ל-AI.

Execution שייך לדפדפן.

Control שייך לכם.

WebMCP הוא הממשק שבו שלושת הכוחות האלה נפגשים.

Architecture > Magic.

מילון קצר

• WebMCP: סטנדרט מוצע שמאפשר לאתרים לחשוף כלים מובנים ל-AI agents דרך הדפדפן.
• Tool / Capability: פונקציה מוגדרת של האתר עם שם, תיאור ו-JSON schema.
• Agentic AI: מערכות AI שמסוגלות לתכנן ולבצע פעולות רציפות.
• Control Plane: שכבה שמנהלת, מגבילה ומבקרת פעולות AI.
• Capability Testing Model: תבנית בדיקה שמשתמשת בכלים דטרמיניסטיים ל-state setup וב-Playwright לאימות UX.
• Prompt Injection: מצב שבו input לא מהימן גורם ל-agent לבצע פעולה לא רצויה.