CLINE INTEGRATION · MCP · OPEN SOURCE
Add Prufa to Cline's MCP config. Ask it to test a URL — Cline drives a real browser and hands back an evidence-gated verdict, not a screenshot to eyeball.
No signup. No card. Public URL in, shareable report out.
In our June 2026 audit of 49 Show HN launches, 78% (38 of 49) shipped a critical bug on day one — and 38 of 49 sent no analytics at all. See the 49-launch dataset.
Cline just built a feature and marked it done. Did it check that the page still works in a browser — that the analytics fire, the security headers are set, the layout doesn't overflow on a phone? Reading the diff doesn't tell you that.
Wire the Prufa MCP server into Cline and it can find out for itself.
Cline calls prufa_run_audit, Prufa loads the URL in a real
browser, captures every beacon, console error, cookie and status code,
runs a fixed suite of deterministic checks against that captured
evidence, and returns the verdict as JSON. Cline reads it, fixes what
broke, and runs it again — all inside its own loop. The first call needs
no key and no card — the same thing as the
free 60-second website audit you can run by hand.
Cline edits files and runs commands well, but it checks its own work badly. It can read a stack trace; it can't see that the signup button does nothing, that the tag manager loaded but never fired an event, or that the hero overflows the viewport on mobile. The usual fix — "open a browser and look" — needs you, the human, back in the loop. The alternative — hand-author a Playwright suite Cline then has to keep green — is the work you were trying to skip. Most "MCP for testing" options are browser drivers: they hand Cline click/type/screenshot primitives and leave the judging to you.
Prufa's architecture is agentic navigation + deterministic verification: an LLM-backed agent loop plans and drives the browser; a plain-code harness owns the session, records all network traffic over CDP, and grades the captured evidence against a versioned spec. The LLM navigates — it never judges whether a tracking beacon is correct. That separation is why the verdict is trustworthy enough for Cline to act on automatically: same input, same verdict (determinism is regression-tested against a golden fixture site). The MCP server is a thin client over that — the same product as our CLI, HTTP API and dashboard, just spoken in tool calls. Read the long version in how Prufa verifies a signup flow.
Three steps: add the server to Cline's config, ask it to test a URL, and read a verdict that only verified evidence can move.
Click the MCP Servers icon → Configure tab → Configure MCP Servers to open cline_mcp_settings.json, then paste the stdio block below under mcpServers. Cline's config is global (extension globalStorage), not a per-repo file.
Say “Run a QA audit on https://myapp.com.” Cline calls prufa_run_audit({ url }). Prufa spins up a real browser, walks the public pages, and captures beacons, console output, cookies and response codes — no test script for you to write.
Findings come back in two tiers. Verified = a machine-checked fact (the check name + captured evidence + a timestamp). Advisory = a clearly-labeled LLM observation, never phrased as broken. Only verified findings move the section grades; there is no composite 0–100 score, ever.
Note for step 1: Cline stores MCP config in the extension's globalStorage, so it applies to every workspace and is not a committable per-repo file. To share it with a team, share the snippet, not a checked-in file.
The exact, copy-pasteable stdio block — with Cline's own
disabled / alwaysAllow keys — and where the
file lives if you'd rather edit it directly.
{
"mcpServers": {
"prufa": {
"command": "prufa-mcp",
"disabled": false,
"alwaysAllow": ["prufa_run_audit", "prufa_get_report"]
}
}
}macOS: ~/Library/Application Support/Code/User/
globalStorage/saoudrizwan.claude-dev/
settings/cline_mcp_settings.json
Windows: %APPDATA%/Code/User/globalStorage/
saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Linux: ~/.config/Code/User/globalStorage/
saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Install the package first so the prufa-mcp command is on
your PATH: pip install prufa-mcp. That's the whole setup.
The server speaks JSON-RPC 2.0 over stdio (MCP protocol
2025-06-18); Cline spawns it as a subprocess. The free
audit tools — prufa_run_audit and
prufa_get_report — work anonymously, with
no key and no card.
Two Cline-specific keys are worth setting. disabled: false
keeps the server live (flip it to true to switch the
server off without deleting the entry). alwaysAllow
auto-approves named tools so Cline doesn't prompt on every call — to
run audits hands-free, set
"alwaysAllow": ["prufa_run_audit", "prufa_get_report"].
For persistent tools (saved monitors, run history, Gremlin chaos runs)
add a workspace key under env —
"env": { "PRUFA_API_TOKEN": "prk_…" }.
An agent can self-provision a free, no-card trial key via
prufa_setup_workspace (it just needs the human's email),
or a human can mint one in the
dashboard for a persistent workspace.
Cline also supports a remote server form
("url" + "headers") instead of
command/args. Prufa's MCP server is
stdio-only today, so use the command form
above; a hosted remote endpoint is on the roadmap, not shipped.
The server is open source — prufa-mcp on PyPI, Apache-2.0,
source at github.com/prufa-dev/prufa-mcp. It registers
20+ tools across three tiers: a free setup tier
(audits, flows, reports), a Pro persistent tier (monitors, alerts,
usage), and Gremlin chaos tools. Every mutating tool takes an optional
idempotency_key, so when Cline retries on a network blip
the API replays the original response instead of re-executing.
Illustrative rows in the real finding shape
(finding_key · evidence) — the keys, tiers and severities
are exactly what the analyzers emit. Verified tier first, never
interleaved with advisory.
You're flying blind — no pageviews, no conversions reaching your analytics. The single most common critical in our June 2026 audit of 49 Show HN launches (38 of 49).
Without a CSP, an injected script has nothing stopping it. In our June 2026 audit of 14 r/SideProject launches, 11 of 14 served no CSP header.
An LLM observation, not a machine-checked fact — excluded from every severity count and grade. Cline's call whether to act on it.
The honest answers to what Cline users ask before they wire a QA tool into the agent loop.
No — and Playwright MCP is genuinely good at what it does. It hands Cline raw browser primitives (click, type, navigate, screenshot); Cline still has to decide what to do and judge whether the result is correct. That's the right tool when you want fine-grained scripted control. Prufa is the opposite contract: one tool call returns a graded verdict — deterministic checks over captured network traffic, tiered into verified vs advisory. Use Playwright MCP to drive; use Prufa to get a verdict without authoring and maintaining a suite. More on the distinction: agentic testing vs scripted testing.
The audit tools (prufa_run_audit,
prufa_get_report) run anonymously — no key, no card,
rate-limited per IP. Persistent tools (monitors, alerts, Gremlin) are
Pro and return a 402 with a checkout hint on the free
tier — explicit, never a silent charge. We don't meter deterministic
checks or pinned-selector flow replays, and a request that never
returns doesn't count.
Yes, by design on Cline's side: MCP config lives in the extension's
globalStorage, so the Prufa server is available in every workspace,
not a per-repo committable file. That's a Cline behavior, not a Prufa
one. If you'd rather scope a QA tool per project, a tool with
project-level config (e.g. Cursor's .cursor/mcp.json or
Claude Code's --scope project) is the better fit; the
same prufa-mcp command works there too.
The audit loads your public pages in a real browser — the same thing a visitor's browser does. It doesn't mutate state. In Gremlin chaos mode, mutations are dry-run by default and only become real on a host you've explicitly authorized; payments are never executed. Flow credentials are write-only — stored encrypted, never returned by any read tool, never placed in an LLM prompt; they're resolved at the tool boundary at run time.
The questions Cline users and their agents ask before wiring a QA MCP server into the loop.
In Cline, click the MCP Servers icon → Configure tab → Configure MCP Servers to open cline_mcp_settings.json, then add {"mcpServers":{"prufa":{"command":"prufa-mcp","disabled":false,"alwaysAllow":[]}}} after running pip install prufa-mcp. The server speaks JSON-RPC 2.0 over stdio (MCP protocol 2025-06-18). The audit tools work anonymously; a workspace key is only needed for persistent tools.
Cline stores it in the extension's globalStorage. On macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json; on Windows under %APPDATA%/Code/...; on Linux under ~/.config/Code/.... It's global — it applies to every workspace and is not a committable per-repo file — so share the JSON snippet rather than a checked-in file when onboarding a team.
Yes. The Prufa MCP server is open source — prufa-mcp on PyPI under Apache-2.0, source at github.com/prufa-dev/prufa-mcp. Its audit tools (prufa_run_audit, prufa_get_report) run free and anonymously: no signup, no card, rate-limited per IP. Persistent tools (saved monitors, run history, Gremlin chaos) require a workspace key and a paid plan, returning a 402 with a checkout hint on the free tier.
Playwright MCP gives Cline low-level browser primitives — click, type, navigate, screenshot — and leaves the judging to you; it's a driver. A QA MCP server like Prufa returns a graded verdict from one tool call: deterministic checks over captured network traffic, split into verified (machine-checked) and advisory (labeled opinion) tiers. Playwright MCP wins for scripted control; Prufa wins when you want a verdict without authoring a test suite.
Or skip the agent and try it yourself: paste a URL, get a shareable report in about a minute. Persistent monitors and Gremlin chaos runs start on Pro ($99/mo), which also includes MCP server + agent-skill access.