Browser MCP inside Cursor is eating context for a 90-second smoke check
I like Playwright MCP inside Cursor.
For unknown bugs it is genuinely useful.
Open the page, inspect the DOM, click around, read the console, figure out why the modal is stuck. That interactive loop is exactly what MCP is good at.
But I realised I was using the same setup for this:
Log in → open settings → change timezone → save → refresh → confirm timezone stayed changed.
The flow was already known.
Cursor still spent half the conversation opening the page, reading snapshots, deciding what to click, re-reading the page and then explaining what it saw.
It worked, but it felt like keeping an entire browser conversation alive for a 90-second smoke check.
So I split the workflow:
Unknown problem: Cursor + browser MCP
Known repeatable check: external CLI
Permanent critical flow: Playwright test in the repo
For the middle layer I’ve been trying Kane CLI from TestMu.
Cursor can read the Kane instructions through the same AGENTS.md-style path and call it after making a change.
Kane runs the objective and gives Cursor structured pass/fail output plus the browser evidence.
So instead of the coding conversation containing every click and page snapshot, Cursor basically gets:
• flow completed or failed
• assertion that failed
• final page state
• evidence from the run
That separation feels cleaner.
I’m not saying MCP always burns too much context. If the agent is debugging something unknown, that context is the whole point.
And I’m not replacing Playwright with Kane. Auth, billing, permissions and stable regression flows still belong in proper tests.
This is specifically for the awkward middle ground where the flow is too repeatable for exploration but not important enough to immediately build and maintain as a permanent test.
Do you keep browser control inside Cursor’s context, or move known checks out into CLI/CI?