MCP for the Browser: Giving a Local AI Agent Access to the Web
Connecting Playwright MCP to Doka: the agent opens sites, clicks buttons, fills in forms, and checks interfaces right in the browser.
Reading a page and controlling a browser are different tasks. The first just needs text from a link. The second needs "hands": open a menu, click a button, fill in a field, and see what happened. A browser MCP server is what gives an agent those hands.
When you need MCP for the browser
The clearest use case is testing a site. An agent can go through a signup form, check several pages after a release, collect errors from the console, and describe exactly where a flow broke.
There's everyday automation too: moving data from an account dashboard into a spreadsheet, gathering info from several pages, filling in a repetitive form. But the closer a task gets to a payment, a publish action, or sending a message, the more it matters to confirm the last step by hand.
Connecting Playwright MCP
Playwright MCP is Microsoft's official
server for controlling a browser. You'll need Node.js and npx to run it.
In Doka, open the right panel → "MCP Servers" → "+ Add server":
- Name:
Playwright. - Command:
npx. - Arguments, one per line:
@playwright/mcp@latest. - Environment variables: leave empty.
By default the server opens a visible browser window, so it's obvious where the agent
navigated and what it's clicking. You can add the --headless argument to run it in
the background, but for a first look, the visible mode is easier to follow.
Once saved, give it a simple task: "open the site's homepage, tell me the title, and don't click anything." Then ask it to follow one safe link.
A browser MCP server isn't a sandbox and isn't a security boundary. Don't hand the agent your main browser profile with personal email, payment info, and active admin sessions.
A separate profile beats your main one
For automation, create a separate account with minimal permissions. Testing an admin panel? Set up a test editor account instead of using the owner's. Working with a storefront? Stop the flow before checkout. Publishing, deleting, submitting a form, and purchasing should only happen after explicit confirmation.
The site itself can also contain content designed to influence the agent. It's worth spelling out boundaries in the task ahead of time: allowed domains, permitted actions, and the point where it needs to stop.
Examples of reasonable tasks
- "Go through the form up to the submit button, list any errors, but don't submit it."
- "Check the mobile layout of three pages and save a list of issues."
- "Collect names and prices from this category, don't navigate to other domains."
- "Reproduce the bug from this description and attach the steps."
Requests like these give the agent a goal while limiting its freedom. "Go do stuff in my browser" sets no boundaries at all.
What to pick: built-in reading or MCP
If you just need to find a fact or summarize an article, a separate server is usually overkill — Doka already reads web pages on its own. Playwright MCP is for when the interface and the sequence of actions matter: clicks, fields, tabs, logins, checking state after a step.
Start with the protocol basics in what MCP is. Other connections — GitHub, Notion, databases — are collected in the server roundup.
If you landed here from a search and haven't tried Doka yet: it's a desktop AI agent that works with files and the terminal on your own computer and acts as a host for MCP servers like the one above. The model can be local, so the content of pages the agent opens never gets sent anywhere. Download it for free.