An MCP server for testing: hands or a verdict?

Search for an MCP server for testing and you get two different things under one name. One kind gives your coding agent a browser: navigate, click, type, read the page. The other kind gives it an answer: did the flow you described work, and where is the evidence. Both are useful. They are not interchangeable, and picking the wrong one is how an agent ends up spending its context window clicking through a checkout it was supposed to verify.

We build Monito, which is the second kind, so read this with that in mind. The first kind is good software and we say where it wins.

What MCP actually adds

The Model Context Protocol is, in its own words, "an open-source standard for connecting AI applications to external systems." A server exposes tools. Each tool has a name, an input schema and, optionally, an output schema. The tools section of the spec says a tool can return structured results in a structuredContent field, and when it declares an output schema, the server must return results that conform to it.

That last part is the one that matters for testing. A typed result is something an agent can branch on. "status: failed, firstFailure: the confirmation email never arrived" is a fact the agent can act on. A page of accessibility tree is raw material the agent still has to interpret, inside its own context, with its own judgment.

So the real question when you choose an MCP server for testing is: what comes back from the tool call? Hands, or a verdict?

Kind one: a browser the agent drives

Playwright MCP is the reference example. Microsoft describes it as an MCP server "that provides browser automation capabilities using Playwright," and it works through "structured accessibility snapshots, bypassing the need for screenshots or visually-tuned models." The tools are browser verbs: browser_navigate, browser_click, browser_type, browser_snapshot, browser_take_screenshot, browser_console_messages, browser_network_requests and so on. It runs locally, so it can open your dev server.

This is the right tool when the agent needs to do something in a browser and you want it to reason about every step: reproduce a bug a user reported, explore an unfamiliar page, scrape a value, poke at a layout. The agent sees the page structure and decides what to click next. Nothing hides between the model and the browser.

That is also the cost. Every snapshot lands in the agent's context, and the agent, not a separate checker, decides whether what it saw counts as working. The Playwright MCP README is candid about the first half of this. Under "Playwright MCP vs Playwright CLI" it says that if you are using a coding agent you might benefit from the CLI with skills instead, because "CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context". It keeps MCP for "specialized agentic loops that benefit from persistent state, rich introspection, and iterative reasoning over page structure."

The second half is the one teams find out later. When the same agent writes the change, drives the browser, and decides the change works, the verdict is the author grading its own work. A browser MCP gives the agent eyes. It does not give you a second opinion.

Credentials are the other thing to look at. The README describes a --secrets option that replaces matching plain text in tool responses, and calls it a convenience, not a security feature. It also says plainly that Playwright MCP is not a security boundary. If the agent types a password into a login form, the agent has the password.

Kind two: a checker that returns a verdict

The other kind of MCP server for testing takes a URL and a sentence about what should happen, runs the check somewhere else, and returns a result. The browser work happens outside the agent's context. The agent gets a status, a reason, and a link to evidence.

Here is what that looks like with Monito's server, from the MCP docs. The agent calls check with a url and an expectation. The tool waits up to four minutes and returns the verdict, the cause when there is one, the duration, the credits spent, a report link, and the first failing check or bug. If the run takes longer, it returns done: false with a run ID, and the agent calls wait_for_run. The run is never started twice. On a failure, get_run returns the bug reports with reproduction steps, failed requests, console errors and screenshot names, so the agent can diagnose and fix the code. Then it calls check again.

The default toolset is seven tools: check, save_check, get_run, wait_for_run, list_projects, list_scenarios and run_scenario. That is deliberately small. Fewer schemas in context, and every tool does one job in the loop. The full tool catalog (scenarios, discovery, defects, automations, fixtures) is opt-in with toolsets=all.

Three details are worth more than the feature list:

The result has a third state. A run ends passed, failed, or error. Error means the check could not verify the scenario. It is not a pass and it is not a bug in your app. We wrote a whole post on what "cannot verify" means because agents, like people, want to round it to one of the other two. An agent that treats error as "ship it" is worse than no check.

Secrets stay out of the tool arguments. Some commands have no MCP tool on purpose. monito credential set is one: login secrets never pass through tool arguments, and API keys are not created over MCP because that would put a secret in the agent's context. Saved logins are entered by the executor, which keeps credential values out of model commands and responses. The agent can run a saved scenario that signs in with a saved login role. It never holds the password.

Retries do not double-charge. run_scenario and run_project take a requestId. If the client retries after a dropped connection, Monito returns the first launch instead of starting another. Every run spends credits, exactly as it does from the dashboard or CLI, so this matters when an agent is in a loop.

Hosted or local

Monito's server comes in two forms, and the difference is reach.

The hosted server is https://www.monito.dev/api/mcp. Nothing to install; the client opens a browser to sign in the first time. It works in Claude (web and desktop), ChatGPT, Claude Code, Cursor and VS Code. It checks deployed URLs. It rejects localhost and private-network URLs, so a coding agent working against localhost:3000 needs a deployed preview or the other server.

The local server is npx -y @monitodev/cli mcp. It reuses monito auth login, needs Node.js 20 or later, and runs in clients that can launch local commands. It can reach HTTP localhost through a built-in tunnel: pass a loopback URL to check, or localPorts for up to three ports. Keep the server and the dev server running until the verdict. It also carries the CI setup tools, because those read the repository and write a GitHub Actions workflow. The details and limits of local checks are in checking localhost.

Either way the browser runs in Monito's cloud. The local server only changes what the cloud browser can reach.

Which one you want

These are not competitors so much as different jobs.

Use a browser MCP like Playwright MCP when the agent needs to work in a browser: reproduce, explore, extract, or iterate on UI with full visibility. Use it when you want the model to see the page and you are fine paying for that in context. Use it when there is no verdict to give, because the task is not "does this work" but "do this."

Use a verdict MCP when the question is "does this flow still work after my change?" Use it when the answer should come from something that did not write the change, should carry evidence you can open later, and should not consume the agent's context on every click. Use it when the agent should never see the test account's password.

If you use both, split them along that line: let the agent drive a browser while it builds, and make it ask for a verdict before it says it is done. Setup per client is in Claude Code, Cursor and Codex, and the coding agent post covers the CLI path for agents that prefer a shell command to an MCP call.

What Monito's MCP server does not do

It does not heal a failing scenario. If the product changed on purpose, you update the sentence. It does not choose which flows matter. It runs Chromium only. A local check cannot be scheduled, put in a suite, or shown on a status page, even after saving; those need a deployed Environment. And it is not free per run. Prices are on /pricing: A standard test is 1 credit, an Advanced test is 10, and Discovery is 20. Pro is $79/month for 700 credits. Team is $199/month for 1,800 credits. Managed is $750/month, limited to 10 teams, and includes the Team allowance. 50 free test credits every month. Your balance refills to 50 on the 1st of each month (UTC), counting credits reserved by running tests. Unused credits are not added again; purchased credits are kept. Your signup credits count as the first month. Free includes one daily schedule. Verify your email to receive monthly refills. The onboarding wizard does not charge its first run. Pricing.

If you need the agent to see and steer every step, that is a browser MCP's job, and you should use one.

Try it

Add the hosted server to Claude Code:

claude mcp add --transport http monito https://www.monito.dev/api/mcp

Run /mcp, choose monito, and sign in. Then give the agent a change and a sentence it can be checked against:

I just changed the signup form validation. Use the monito check tool on
https://staging.yourapp.com/signup with this expectation:

"Submitting the form with the email 'not-an-email' shows an inline error
next to the email field, does not show a success message, and does
not navigate away. Submitting a fresh valid email and a 12-character password
reaches the onboarding page."

If the result is failed, call get_run, read the first failure and the
failed network requests, fix the code, and check again. If the result is
error, do not treat it as a pass: read the cause and tell me what it says.
When it passes, save it with save_check and name it "Signup validation".

The last paragraph is the part worth copying into your agent instructions. A verdict is only useful if the agent is told what to do with each of the three answers.