End-to-End (E2E) Testing With an AI Agent: Should Cursor Drive Playwright MCP or Kane CLI?

What Does Each One Actually Do?

Playwright MCP is a browser tool server for an AI agent. Its Playwright MCP README describes a server that lets LLMs "interact with web pages through structured accessibility snapshots, bypassing the need for screenshots or visually-tuned models." Its tools, such as browser_click, take an "exact target element reference from the page snapshot", so Cursor's model reads a snapshot first and then acts on what it found.

Kane CLI is a browser agent rather than a tool server. Cursor writes a natural-language objective into a kane-cli run command; Kane CLI drives a real Chrome instance through the Chrome DevTools Protocol with its own model, checks the outcome against evidence, and returns one structured result.

That difference decides everything downstream, including how much Cursor reads and who calls the result. If the server itself is new to you, the guide to the Playwright MCP server covers its tools before any of this comparison matters.

How Do the Setups Compare?

Cursor's MCP docs show how to add an MCP server for one project in .cursor/mcp.json, or for every project in ~/.cursor/mcp.json.

Cursor's Run Modes docs say they "control how the Cursor agent runs tool calls, and when Cursor interrupts you for approval." Auto-review "applies to shell, MCP, and Fetch tool calls" and sends calls that are not allowlisted to a classifier, while in Allowlist mode only "Actions in your allowlist run without approval." Cursor 3.6 shipped Auto-review "as the recommended default," and only Run Everything lets "Every tool call" run automatically.

The Playwright MCP entry, as its README gives it, then the Kane CLI setup and the command Cursor ends up running:

# Playwright MCP: .cursor/mcp.json
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

# Kane CLI: install, sign in with an access key, check the account
npm install -g @testmuai/kane-cli
kane-cli login --username "$LT_USERNAME" --access-key "$LT_ACCESS_KEY"
kane-cli whoami

# then, in Cursor's agent chat:
# "Use Kane CLI to verify the cart flow: testmuai.com/kane-cli/agents.md"

# the command Cursor runs, in agent mode for NDJSON output
kane-cli run "Search for 'iPhone' using the search box, open the first iPhone product in the results, click Add to Cart, then open the shopping cart and assert the cart contains a product named 'iPhone'" \
  --url https://ecommerce-playground.lambdatest.io/ \
  --agent --headless --name iphone-cart --timeout 600

The Kane CLI with AI coding agents docs cover the Cursor setup step by step, including why an agent should sign in with an access key rather than a browser login.

Who Owns the Selectors and the Maintenance?

Playwright MCP's element references live only as long as the snapshot that produced them. In my run, the search box was e216 on the home page, and after the next navigation the references came back with a new prefix, such as f1e495 for the product link. Nothing about how Cursor found an element survives the session.

What does survive is code. Each click and type response included a "Ran Playwright code" block with a role-based locator, and the opt-in browser_generate_locator tool, enabled with --caps=testing, turns an element into a locator, so Cursor can write a Playwright spec from the session. From then on, the locators are yours to keep current through every redesign.

Kane CLI keeps the objective instead. The run saved with --name became a 303-byte iphone-cart_test.md holding the sentence, plus a cached recording that replays without a model.

• Playwright MCP's maintenance surface - The Playwright code Cursor writes from the session: locators, waits, and assertions, all versioned with the app and all needing an update when the UI changes shape.
• Kane CLI's maintenance surface - The wording of the objective. A cached step that no longer matches the page needs re-authoring, and a vague objective can be satisfied by the wrong screen.
• What a UI change looks like in Kane CLI - In the Claude Code walkthrough in the Kane CLI docs, a replay failed after a button was renamed from Create to Add project. The agent edited that one step so it re-authored against the new UI.

Neither surface is free. The question is which one your team can keep accurate as the product moves.

Which One Fits an AI Coding Agent's Loop?

This is where the two diverge most, so I measured it. The flow ran on TestMu AI's Ecommerce Playground: open the store, search for "iPhone", open the first result, add it to the cart, and confirm the cart lists an iPhone.

• Playwright MCP 0.0.83 - I connected through the official MCP SDK client, the same protocol Cursor uses, and made the tool calls a Cursor agent would make, without a model in between. That isolates what the tools themselves return.
• Two reading strategies - In the first, the agent reads the page with a full browser_snapshot before each action. In the second, it uses browser_find, which searches the snapshot and returns only matching nodes.
• Why the second read is needed - In 0.0.83, action tools such as browser_navigate and browser_click save the snapshot to a file and return only a link, so the agent has to ask for the page again before its next action.
• Kane CLI in agent mode - I ran the same flow as one objective with --agent --headless, then replayed the saved test.
• Token counts - Every response was counted with the o200k_base tokenizer. Cursor's models tokenize slightly differently, and the counts leave out Cursor's own reasoning, which grows with each of the 12 Playwright MCP turns.

All four runs confirmed an iPhone in the cart. The per-call log shows where the tokens went:

• Snapshots are the cost - With full snapshots, four page reads made up 41,385 of the 42,333 tokens. The store's home page alone was 20,116 tokens, a 1,360-line accessibility tree with 1,156 element references.
• browser_find helps, if the agent knows what to look for - Searching for "Search For Products" or "Add to Cart" cut the reads to a few hundred tokens each. The search-results page still returned 2,241 tokens, because "iPhone" matched every product card.
• Kane CLI's result is small and structured - Cursor can read only the final run_end line, which carries the status, a summary, and the values Kane CLI extracted. Kane CLI's own model work is billed as credits, outside Cursor's context.
• Approval checks add up - The Playwright MCP flow made 12 MCP tool calls, which means 12 prompts under an empty allowlist or 12 classifier reviews under Auto-review. The Kane CLI command needed at most one, and only Run Everything skips the checks.

Microsoft makes the same point in its own README, recommending that coding agents favor CLI workflows "because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context." The broader trade-off is covered in MCP vs CLI.

How Do They Behave in CI?

A pipeline needs a verdict it can gate on, and the two tools produce that very differently.

With Playwright MCP, the verdict is Cursor's judgment. The server does ship assertion tools, such as browser_verify_text_visible and browser_verify_element_visible, but they are opt-in through --caps=testing. Without them, "the cart has an iPhone" means Cursor read a snapshot and concluded so, and nothing produces an exit code a pipeline can gate on. For CI, the usual path is to have Cursor write a Playwright spec and run that with the Playwright test runner.

Kane CLI makes the verdict part of the output. Here is the run_end line from the first run, trimmed:

{
  "type": "run_end",
  "status": "passed",
  "one_liner": "added an iPhone to the cart on LambdaTest Ecommerce Playground",
  "final_state": {
    "url": "https://ecommerce-playground.lambdatest.io/index.php?route=checkout/cart",
    "cart_contains_iphone": "true"
  },
  "reason": "Objective completed",
  "duration": 96.7,
  "credits_consumed": 22.785712500000002,
  "result_code": 100,
  "reason_code": "success.complete"
}

• The full line also shows how the assertion was checked: a DOM check that the cart row's text equals "iPhone", with the locator it used.
• The process exited with code 0. The Kane CLI reference lists 1 for a failed assertion, 2 for an error such as a Chrome or auth failure, and 3 for a timeout, so CI can tell a broken feature from a broken environment.
• Combine --agent with --headless on any runner without a display server, and sign in with an access key, since an OAuth login needs a browser window the runner does not have.
• The run sealed an evidence pack on disk with 9 step screenshots, a HAR network log, console logs, and the test definition.

Should You Run Both Together?

For most teams using Cursor, yes. Playwright MCP's README says MCP "remains relevant for specialized agentic loops that benefit from persistent state, rich introspection, and iterative reasoning over page structure", and that describes real jobs inside the editor:

• Debugging while you code - Cursor can open the page, read console messages and network requests, and change the code in the same session.
• Drafting Playwright tests - The per-action code blocks, plus browser_generate_locator when --caps=testing is on, give Cursor real locators for a spec your team already runs.
• No account, no credits - It runs on Node.js 18 or newer, so a quick look at a page costs only Cursor's tokens.
• Fine-grained control - Opt-in capability groups add storage, network mocking, tracing, video, and PDF tools when a task needs them.

The README is also direct that "Playwright MCP is not a security boundary", so treat what it reads as untrusted input to Cursor. A split that works puts each tool where its cost profile fits: Playwright MCP while Cursor builds, Kane CLI when the feature is done and needs a verdict.

Kane CLI's saved test is what makes the second half cheap. The replay of the cart flow reported this:

kane-cli testmd run .testmuai/tests/iphone-cart_test.md --agent --headless

# from the NDJSON stream
"replay_started"   "replaying 9 actions"
"replay completed" duration 13.69
"replay_decisions": 1, "author_decisions": 0
{"type":"test_md_done","overall_status":"passed","duration_s":23}

Zero author decisions means no model was asked to work anything out, which matches the Kane CLI Test.md docs: after the first run, steps replay from cache "with no LLM cost." The first run also produced a Playwright Python export in which four of the five locators were role-based, so a flow that starts as an objective can still end up in a Playwright suite. The file format behind that round trip is covered in Test.md, and the side-by-side capability table lives on the Playwright MCP alternative page.

Which Should You Choose?

Match the tool to the job in front of you rather than to a feature count:

Conclusion

Take the one journey your team would least like to ship broken and run it both ways from Cursor this week: once with Playwright MCP connected, once as a Kane CLI objective. Compare what each put into Cursor's context and which answer you would trust in a pull request.

Start with npm install -g @testmuai/kane-cli and the Kane CLI quickstart, which gets a first objective running in a real Chrome browser.