Monito with Claude Code

Give Claude Code a URL and what should happen. Monito returns the verdict and browser evidence without requiring a saved test.

Check your change from the terminal

Install the CLI and sign in once:

npm install -g @monitodev/cli
monito auth login
monito check https://preview.example.com/signup "The form rejects a malformed email" --json

Monito waits for a verdict and returns checkId, projectId, runId, status, cause when available, duration, credits, reportUrl, and the first failing check or bug. Exit 0 means passed; 1 means failed or error. Use --max-duration <ms> (60000–600000) to set the run's budget. --timeout 600000 sets the CLI wait limit. For deployed URLs, use --no-wait to return IDs immediately. For deployed URLs, on timeout (exit 6), resume with monito run wait <runId> --json; launching again spends credits again.

Check localhost

Start your dev server, then check its URL or give the start port:

monito check http://localhost:3000/cart "The cart shows the added item" --timeout 600000 --json
monito check --local 3000 "The home page loads" --json
monito check --local 3000 --local 4000 "The page loads data from the API" --json

localhost, 127.0.0.1, [::1] and names ending in .localhost imply a local check. Repeat --local for up to three distinct ports; the first is the start port when no URL is supplied. Ports must be from 1024 through 65535. Local checks use HTTP; local HTTPS is not supported. Use --project <projectId> to keep them in your app's project, under its local (tunnel) environment.

Before creating a run, Monito sends a GET to the start path on 127.0.0.1, then tries ::1 if the connection is refused. This warms a dev-server compile. Any HTTP response, including a 500, allows the check to start. If neither address is listening, it stops with “Nothing is listening on localhost:3000. Start your dev server and retry.” No run is created and no credits are spent.

Keep the CLI process and dev server running until the verdict. Avoid editing files during the check: hot reload can change the page being tested. --no-wait is unavailable for local checks. Set the agent's command timeout long enough for the check as well as using --timeout 600000. If the CLI wait times out (exit 6), the tunnel closes when the process exits and the run ends as “tunnel closed”; monito run wait can read that ending, but cannot restore the tunnel.

The local stdio MCP server (monito mcp) also accepts loopback URLs in check, with an optional localPorts: [3000, 4000]. Keep the server process running. Its tunnel stays alive after a tool call's wait limit; use wait_for_run to resume. Hosted MCP cannot reach localhost; use the local server setup for these checks.

Saved logins and request headers are not available for local checks. Use an app with seeded or dev auto-login when authentication is needed. Dev builds may show source paths and stack traces in evidence. --verbose prints each request's method, path without its query, status and duration to stderr. The tunnel token stays in memory and is omitted from JSON and logs.

Keep checks in your project

Without a project selection, Monito matches the URL's origin against any environment you own, or creates a project from the host when nothing matches. Checks show in Runs with a Check label and stay out of saved-test lists, suites, Discovery coverage and status pages until saved.

For Vercel, Netlify, and other deployment previews whose hostname changes, pass your existing project ID so every deployment stays in the same project:

monito check https://monito-x1y2z3-team.vercel.app/signup "The form rejects a malformed email" --project <projectId> --json

For deployed URLs, Monito selects an environment with a matching origin, falling back to the project's default. A preview on a different origin keeps its full URL. In MCP, pass projectId to check; optionally pass environmentId to choose an owned environment in that project. Its settings apply while the check still visits the supplied URL.

Each CLI invocation or MCP call generates a request ID. For retries after an uncertain network response, supply the same --request-id <id> (CLI) or requestId (MCP/API) to reuse the original check and run without another charge. A new invocation without an explicit ID starts a new check.

Keep it as a test

monito check save <checkId> --name "Signup validation"

Or use Save as test on the report. The saved test retains its run history; add an automation separately to monitor a deployed check. Local checks cannot be monitored, scheduled or added to suites, automations or status pages, even after saving.

Connect MCP

Connect the hosted server:

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

Run /mcp in Claude Code and sign in to Monito. This uses Claude Code's HTTP MCP setup.

The default tools are check, save_check, get_run, wait_for_run, list_projects, list_scenarios, and run_scenario. Ask the agent:

Use Monito to check that https://preview.example.com/signup rejects a malformed email. Show the verdict and report link. If the wait ends, resume the same run.

Use save_check with a name when you want to keep it. For the full catalog, add ?toolsets=all to a hosted URL or --toolsets all to the local server arguments. Explicit lists such as check,core,defects also work. See MCP tools.