Website to MCP: Weft vs Playwright MCP vs Scraping — Which Should You Use?
Three ways to give Claude or Cursor access to a website: call the site's own API with Weft, drive a browser with Playwright MCP, or scrape HTML. How each works, what it costs in tokens and reliability, and when to pick which.
"Give my AI access to this website" can mean three very different architectures. Picking the wrong one is why so many website-to-MCP setups feel slow, flaky or expensive. Here's how the three main approaches compare — including the one I built, Weft — and an honest take on when each wins.
Approach 1: Call the site's own API (Weft)
Weft learns the JSON/GraphQL endpoints a website's front end calls while you use it, then exposes them as MCP tools. Calls run inside your logged-in browser tab, so the response is the same structured data the page renders from.
- Output: clean JSON — cheap in tokens, easy for the model to reason over.
- Speed: one HTTP request per question, no page rendering.
- Auth: your existing session; credential values never leave the browser.
- Breaks when: the site changes its internal API (Weft flags the site Outdated; re-capture fixes it).
- Can't do: sites with signed requests, WebSocket-only data, or purely visual tasks.
Approach 2: Drive a browser (Playwright MCP)
Microsoft's Playwright MCP gives the model a real browser. It reads pages through accessibility snapshots and acts by clicking, typing and navigating — like a very fast intern.
- Output: page snapshots — far more tokens per step than a JSON response.
- Speed: several steps per task, each rendering a page.
- Strength: works on anything a human can do in the UI, including multi-step flows and sites with no usable API.
- Breaks when: layouts change, or the model clicks the wrong thing.
Approach 3: Scrape the HTML
Fetch pages and parse the HTML, either with a hand-written scraper or a generic "fetch URL" MCP tool. Fine for public, static content; poor for logged-in apps, because the data you want is usually rendered by JavaScript from an API call — which is exactly what approach 1 calls directly.
Side by side
- Read your own data from a logged-in web app (stats, issues, orders): Weft.
- Complete a multi-step UI flow (fill a form, click through a wizard): Playwright MCP.
- Read public articles or docs pages: a fetch/scrape tool.
- The site has an official API and MCP server: use that — it's the supported path.
- You're building a product on top of a site's data: use the official API; reusing a personal session is for personal workflows.
They combine well
These aren't exclusive. A practical setup is Weft for fast, structured reads across the tools you live in, plus Playwright MCP for the occasional task that really needs clicking. Because MCP clients can load several servers at once, the model picks the right tool per step — cheap JSON when it exists, a browser when it doesn't.
To try the API-first approach, follow How to turn any website into an MCP server, or watch the two-minute demo with Medium and Claude Code.
Frequently asked questions
What's the difference between Weft and Playwright MCP?
Weft calls a website's own JSON/GraphQL API through your logged-in browser session and returns structured data. Playwright MCP drives a real browser by clicking and reading page snapshots. Weft is faster and cheaper for reading data; Playwright is better for multi-step UI tasks.
Is scraping a good way to connect a website to MCP?
Only for public, static pages. Logged-in web apps usually render data from an API call, so calling that API directly (as Weft does) is more reliable than parsing the HTML.
Can I use Weft and Playwright MCP together?
Yes. MCP clients like Claude Code and Cursor can load several servers at once, so the model can use Weft for structured reads and Playwright MCP for UI flows.