Flag failed playwright executions as tool errors

[masnwilliams]

Summary

execute_playwright_code returned its failure payload without isError, so a request that never reached the browser was recorded as a successful tool call. This sets isError: true on that path.

The response body is unchanged — same { success: false, error } shape — so anything parsing it keeps working.

Why

Over a 21-hour window the tool made 3,769 API calls with 83 failures (34 × 400, 48 × 499, 1 × 500), and reported 5. It is ~81% of all MCP tool traffic, so error-rate monitoring for the whole server was effectively blind to its busiest path.

Scope: only failures where the code never ran

The catch block covers requests that failed outright. The API's 400s on this route are all lifecycle or protocol problems — missing body, session has already been deleted, session is not currently leased, browser not found — plus 5xx.

Code that ran and threw inside the browser still comes back as a 200 with success: false and is not flagged. A selector that didn't match is a normal result an agent should read and adapt to; marking it a tool error would invite retry loops and drown the real signal.

Verification

Ran the route locally against a failing call and confirmed the captured analytics event flips to $mcp_is_error = true (previously false for the same failure), with no message, parameters, or response captured.

tsc --noEmit passes. Note prettier --check already fails on this file on main; the pre-existing formatting is left alone rather than reformatted in this diff.

---

Note

Low Risk
Narrow change to MCP tool metadata on an existing error path; response body unchanged and in-browser success: false behavior is untouched.

Overview
execute_playwright_code now returns isError: true when the Kernel API call fails in the catch path (session missing/unleased, bad request, timeout, etc.), so MCP analytics and error monitoring treat those outcomes as failed tool calls instead of successes.

The JSON body is unchanged ({ success: false, error }). In-browser failures that still return HTTP 200 with success: false are intentionally not flagged—only cases where no normal API response came back.

^{Reviewed by Cursor Bugbot for commit e9702e4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mcp	Ready	Preview	Jul 31, 2026 9:46pm

[dcruzeneil2]

Approved. Correct fix: the catch block only fires when the API call itself fails (deleted/unleased session, bad request, 5xx), and those genuinely are tool errors — flagging them with isError: true matches the errorResponse convention used elsewhere in this repo. Keeping in-browser failures (200 + success: false) unflagged is the right call; those are results the agent should adapt to, not retry. Body unchanged, so no parser breakage.

One nit, take or leave: the comment says "the code never ran," but a timeout can throw after execution started — maybe soften to "no normal API response was received."

[masnwilliams]

Taken — fair point, a timeout can throw after execution has started. Reworded to describe the response rather than the code:

No normal API response came back -- the session was gone, unleased, the request was rejected, or it timed out. Distinct from code that ran and threw, which comes back as a 200 with success: false so the agent can read the failure and adjust.

Only the comment changed; isError: true and the response body are untouched.