Browser testing MCP server
Connect an MCP client to Monito over Streamable HTTP and OAuth. Choose toolsets, run browser checks and inspect verdicts, credits and error codes.
Coding agents · Checked 2026-10-23
Use typed MCP tools to check a deployed URL, read its evidence and save the check as a test. The hosted endpoint is https://www.monito.dev/api/mcp.
How it works
- Your client connects over Streamable HTTP, signs in with OAuth, and calls check with a URL and expectation.
- Monito runs the browser check using your account's credits. An unfinished call returns done: false and a runId to resume.
- The tools return a short summary and structured JSON. Follow get_run to the evidence and get_screenshot to the image.
Set it up
Browser checks use credits without a subscription requirement. OAuth and CLI browser sign-in do not require an API key. Creating API keys, CI bindings or deploy webhooks requires Pro or Team. Plan details
- Add https://www.monito.dev/api/mcp as a Streamable HTTP server in your client. The example below uses Claude Code; the client guide covers other configurations.
- Sign in to Monito in the browser and choose Allow for the client you connected. It acts through MCP as your Monito account.
- Start with the default check,core-read toolsets. Add ?toolsets=all to the hosted URL or pass --toolsets all to the local server when you need the full catalog.
claude mcp add --transport http monito https://www.monito.dev/api/mcp
Example Streamable HTTP client registration. Run /mcp in Claude Code to complete OAuth sign-in.
Follow the verdict to the evidence
Call check with url and expectation, for example your deployed cart URL and "The total includes shipping". Keep projectId stable for previews whose hostname changes.
When done is false, call wait_for_run with the returned runId. Do not launch another check just to keep waiting. Reuse requestId after an uncertain launch response to avoid another charge.
Call get_run with runId to read the verdict, bug reports, failed requests, console messages and screenshot names. Then call get_screenshot with run.sessionId and a fileName from evidence.screenshots, not a screenshot URL.
After a fix, call check again. Use save_check with checkId and a name to keep a deployed check as a test; add its automation separately.
Default tools and the local server
The default tools are check, save_check, get_run, get_screenshot, wait_for_run, list_projects, list_scenarios, list_runs, run_scenario, and run_project.
In CLI 4.8.1, the local server's check,core-read default has seven tools and leaves out list_runs, run_project, and get_screenshot. Pass --toolsets check,core to include them; that also adds the rest of the core toolset, including tools that create and change scenarios. The hosted server includes all three by default.
npx -y @monitodev/cli auth login npx -y @monitodev/cli mcp --toolsets check,core
Use this command as your client's local server to include screenshot access on CLI 4.8.1. Sign in once before starting it. Keep both the MCP server and your dev server running for localhost checks.
Toolsets, credits and errors
Available toolsets are check, core-read, core, manage, discovery, defects, automations and fixtures. The ci toolset is local-only because it reads your repository and runs GitHub setup commands. Explicit comma-separated selections work in the toolsets query parameter or local --toolsets argument.
Browser runs use the same credits as the dashboard and CLI. Use get_credits through core or all to read the balance. run_project charges each launched scenario and selects the newest 20 saved scenarios, or a suite whose members all fit in that page.
Run tools wait up to four minutes by default. Resume done: false with wait_for_run instead of spending credits on another launch.
Tool errors use auth, not_found, validation, insufficient_credits, plan_required, timeout, network, server and conflict. Credit and plan errors include a link to manage your plan. An error code describes a failed tool call; a completed browser run with status error is not a product verdict.
Example result
Example result: field names from the CLI, values illustrative
These verdict fields come from CLI 4.8.1 check --json. This illustrative failure describes a cart total that omits shipping. Timing and billing values are left null in this example. Use the returned reportUrl for the actual evidence.
{
"checkId": "check_example",
"projectId": "project_example",
"runId": "run_example",
"done": true,
"status": "failed",
"cause": "product_defect",
"causeLabel": "App bug",
"durationMs": null,
"creditsCharged": null,
"reportUrl": "https://www.monito.dev/session/session_example",
"firstFailure": "The cart total does not include shipping."
}Limits to account for
The hosted server at https://www.monito.dev/api/mcp tests deployed URLs. It rejects localhost and private-network URLs. The local server, npx -y @monitodev/cli mcp, reaches HTTP localhost through a tunnel; the browser still runs in the cloud.
Local checks have no saved logins or request headers. They cannot be scheduled or added to suites, automations or status pages, even after saving.
A failed run reports a bug. An error is not a verdict about your app. Read the evidence before asking your agent to change code.
A connected app can read and change projects, scenarios, automations and fixtures, and spend credits on runs. Its token cannot create API keys, change your plan or manage connected apps. Disconnect it in Settings, Connected apps; already-started runs continue.
MCP tools never receive saved-login secrets as arguments. Configure logins in the dashboard or CLI. Tools that delete data require confirm: true.
Comparable benchmark runs
Our team published these runs in the reliability benchmark. They show comparable browser journeys, not executions of the configuration or illustrative result above. Run your own scenario before relying on this integration.