Debugg AI — MCP Server

AI-powered browser testing via the Model Context Protocol. Point it at any URL (or localhost) and describe what to test — an AI agent browses your app and returns pass/fail with screenshots.

Setup

Requires Node.js 20.20.0 or later (transitive requirement from posthog-node@^5.26.0).

Testing http://localhost:... URLs requires the caddy binary — check_app_in_browser, probe_page, and trigger_crawl tunnel localhost targets through a local Caddy reverse proxy. This installs automatically: the @radically-straightforward/caddy npm dependency downloads a pinned Caddy release for your platform during npm install/npx — nothing to install yourself in the normal case. It is now the only binary this package downloads; the tunnel client itself is pure TypeScript — it replaced the ngrok package, which fetched the ngrok agent. If that download never ran (npm install --ignore-scripts, an offline/air-gapped install), point CADDY_BIN at your own install (brew install caddy / apt install caddy / see caddyserver.com/docs/install) — missing it surfaces as a clear error on the first localhost-URL call, not a silent hang. Public-URL calls, every non-browser tool, and test_suite {action:"run"} (which uses its own dedicated tunnel and bypasses Caddy entirely) don't need it either way.

Related MCP server: QAcito

Testing a local app (no Tailscale, no port exposure)

Start your app on localhost, then pass the http://localhost:<port> URL straight to the tool. The MCP opens its own DebuggAI tunnel (one per session, dialed through a local Caddy proxy) — do not expose the port with Tailscale, ngrok, or anything else, and do not rewrite the URL to a tunnel hostname yourself.

probe_page            { "targets": [{ "url": "http://localhost:4040" }] }
check_app_in_browser  { "url": "http://localhost:4040", "description": "Open the home page and confirm the hero renders" }

Verified 2026-11-10 against a Next.js dev server on localhost:4040: probe_page returned statusCode 200, title, 0 console errors, and every asset request resolved via the tunnel. Prerequisites: DEBUGGAI_API_KEY set for the MCP, the caddy binary available (see above), and the app actually listening (a dead port fails fast with LocalServerUnreachable). Several pages on the same port can share one probe_page call; mixing ports in one call works but runs serially.

TunnelTrafficBlocked means the tunnel came up but the health probe through it got no valid response. First check you are on the latest MCP (npx -y @debugg-ai/debugg-ai-mcp@latest; a stale pinned version is the usual cause), then that your dev server answers a plain curl http://127.0.0.1:<port>/ and does not reject unknown Host headers (tunnel requests carry the tunnel hostname; a gateway that routes by Host needs a catch-all). Verified 2026-11-10: servers bound to 127.0.0.1 only (IPv4 Caddy gateways on :4040 and :4043) probe fine via http://localhost:<port> and http://127.0.0.1:<port>.

Get an API key at debugg.ai, then add to your MCP client config:

{
  "mcpServers": {
    "debugg-ai": {
      "command": "npx",
      "args": ["-y", "@debugg-ai/debugg-ai-mcp"],
      "env": {
        "DEBUGGAI_API_KEY": "your_api_key_here"
      }
    }
  }
}

Or with Docker:

docker run -i --rm --init -e DEBUGGAI_API_KEY=your_api_key quinnosha/debugg-ai-mcp

The Dockerfile's npm install step would pick up caddy the same automatic way local installs do, in principle — but as of this writing the Dockerfile doesn't COPY several directories the build now needs (handlers, tools, types, config) and still references a tunnels/ directory that no longer exists, so a fresh build likely fails before that matters. That's a pre-existing gap, unrelated to Caddy. The currently published quinnosha/debugg-ai-mcp image predates the Caddy dependency regardless — localhost-URL calls to check_app_in_browser/probe_page/trigger_crawl will fail with CaddyBinaryNotFoundError inside that image until it's rebuilt (Dockerfile fixed) and republished, or CADDY_BIN points at one baked in separately. Public-URL calls, the non-browser tools, and test_suite {action:"run"} are unaffected either way.

Tools

The server exposes 8 tools: three Browser tools plus one action-based tool per managed entity. The headline tools are check_app_in_browser (full AI agent) and probe_page (lightweight no-LLM page probe). The rest — project, environment, test_suite, test_case, executions — each take an action discriminator (e.g. {"action":"list"}) that selects the operation. Destructive delete actions require confirmation (an elicitation prompt where supported, otherwise confirm: true).

Browser

check_app_in_browser

Runs an AI browser agent against your app. The agent navigates, interacts, and reports back with screenshots. Localhost URLs are auto-tunneled through the debugg tunnel server.

One focused check per call. The agent has a ~25-step internal budget; split broader suites across multiple calls.

Credentials: pass them as parameters, not prose

Naming an account only in description does not make the agent use it — it falls back to the environment's stored credential, and the app's rejection of the wrong account comes back looking like an application failure. Anything you pass as a parameter beats the environment default for every login in the run, not just the first:

• username / password (or credentialId / credentialRole) — the run's identity.

• auth.username / auth.password — pins the precondition login when you also use auth.precondition: "login".

• loginCredentials — accounts for a login form the agent reaches part-way through the task. This is the one for flows like set a password → get bounced to sign-in → log in as the account you just created, where splitting into separate calls would lose browser state.

Set useEnvironmentCredentials: false when a silent fallback to the default test user would invalidate the check.

Cross-domain SSO? A run only types credentials on the app's own host and its subdomains; a sign-in page on another domain is refused as offscope_host. Add the identity provider's host to the environment's authorizedCredentialHosts (see environment).

Checking a page that needs no login at all? Pass useEnvironmentCredentials: false and name no account. That combination means exactly what it says — do not log in — and the run skips authentication entirely instead of hunting for a login form. Use it for public pages, marketing sites, docs, and anything pre-auth. It is also faster: on the default (auto) the agent will follow a "Log in" link off your page and try the environment's stored account before it evaluates anything.

Session reuse: why a check can report "no login form"

Runs don't log in every time. After a verified login the backend captures that account's session and restores it on the next run for the same identity, which skips the login entirely — that's why a check can legitimately come back with submitted: false and no login form: it was already signed in. A restored run reports itself in logins with reason: "restored_session", so you can tell it apart from a run that genuinely found no form.

Sessions are keyed per account, so naming a different account never reuses somebody else's. Two ways to bypass reuse:

• freshSession: true on a single call — log in for real this once, then re-capture. Use it when the login flow is what you're checking, when you suspect the stored session is stale, or when the app's only route between personas is a logout.

• environment tool, action: "clearSessions" — invalidate the stored sessions so subsequent runs log in. Narrow with username / credentialId; unscoped clears require confirmation because every account on the environment then re-authenticates.

Use action: "sessions" to see what an environment is currently holding and whether each would be reused.

Results report the identity actually used, so a wrong one is visible rather than masquerading as a broken app:

"logins": [
  { "username": "qa+invitefix@example.com", "source": "task", "submitted": true, "authenticated": true },
  { "username": "qatest123@example.com", "source": "env_default", "submitted": false, "authenticated": false,
    "reason": "offscope_host", "detail": "refused to enter credentials on auth.idp.example: not part of this run's scope …" }
],
"credentialWarning": {
  "requested": "qa+invitefix@example.com",
  "used": ["qatest123@example.com"]
}

source is task | explicit | credential_id (an account you named) or env | env_default (the environment's stored account). submitted is true only when credentials were actually typed and submitted; reason says what happened (e.g. offscope_host, restored_session), and detail, when present, is a human-readable explanation of it — for an offscope_host refusal it names the host and how to authorize it. credentialWarning appears only when you named an account and an environment default for a different account was actually submitted — never for a login that was refused or skipped. loginError appears when a named account could not be resolved and the run declined to substitute a different one.

Every successful run returns a browserSession block alongside the screenshot — presigned S3 URLs for the captured HAR (full network trace) and console log (every JS console message). Use them to detect refetch loops, hydration errors, and other runtime issues that pass type-checks and unit tests:

"browserSession": {
  "harUrl": "https://...session_18139.har?X-Amz-...",
  "consoleLogUrl": "https://...session_18139_console.json?X-Amz-...",
  "recordingUrl": "https://...session_18139_recording.webm?X-Amz-...",
  "harStatus": "downloaded",
  "consoleLogStatus": "downloaded",
  "harRedactionStatus": "redacted",
  "consoleLogRedactionStatus": "redacted"
}

URLs are short-lived presigned S3 — refetch the parent execution via executions {action:"get", uuid} to renew. harStatus / consoleLogStatus disambiguate 'downloaded' (URL fetchable), 'not_available' (page emitted nothing), 'failed' (capture broke). On a fresh run the URLs are commonly null because capture uploads async after the agent finishes — poll executions {action:"get", uuid: executionId} until status reaches 'downloaded'. Authorization / Cookie / token/secret/api_key headers are scrubbed server-side before the artifacts are persisted.

trigger_crawl

Fires a server-side browser-agent crawl to populate the project's knowledge graph. Localhost URLs tunnel automatically. Returns {executionId, status, targetUrl, durationMs, outcome?, crawlSummary?, knowledgeGraph?, browserSession?} with knowledgeGraph.skipped === false on successful ingestion. crawlSummary and knowledgeGraph carry only the keys the backend's crawl / import nodes reported — a missing count is absent, never a filled-in 0. The browserSession block (HAR + console-log URLs, same shape as above) is also present on completed crawls.

probe_page

Lightweight no-LLM batch page probe. Pass 1-20 URLs; each navigates, settles on content (the DOM going quiet, bounded — never on network silence, which a live app never reaches), and returns rendered state — screenshot + page metadata + structured console errors + network summary. No agent loop, no LLM cost, no scenario assertions. Use it for "did I just break /settings?", multi-route smoke after a refactor, CI per-PR sweeps, and quick is-it-up checks where check_app_in_browser's 60-150s agent loop is overkill.

All targets in a batch share one session tunnel, but only same-port (or all-public) batches share a single backend execution — 5 URLs on one port in one call is dramatically faster than 5 parallel single-URL calls. A batch that mixes multiple local ports decomposes into one sequential backend execution per port group (still one call, still one merged results[] in your original order, but N backend round-trips instead of one — slower, not rejected). Per-URL error field preserves batch resilience: a single failed target doesn't fail the others.

networkSummary aggregation key is origin + pathname — refetch loops (?n=0..4 repeatedly hitting the same endpoint) collapse into a single entry with the count, so /api/poll showing up with count: 47 is the actionable "infinite refetch loop" signal users originally asked for.

Performance budget: <10s for 1 URL, <25s for 20. Localhost dead-port returns LocalServerUnreachable in <2s without burning a workflow execution.

project

Team and repo resolve by either uuid or name (case-insensitive exact match; NotFound if none, AmbiguousMatch if multiple). There is no update/delete — rename or delete a project from the DebuggAI web app.

environment

projectUuid auto-resolves from the git repo when omitted. Per-cred failures surface in credentialWarnings[] without blocking the env op.

authorizedCredentialHosts lists hosts where a run may enter this environment's credentials besides the app's own host — for cross-domain SSO, add the IdP host here (e.g. ["auth.example.com"]). Bare hostnames only: no scheme, path, port or wildcard (subdomains of the app's host are already in scope). On update it replaces the list; [] clears it. get/list return it when the server supports it. The response echoes the saved list; if the server did not persist it (older servers ignore the field), the result carries authorizedCredentialHostsWarning: {requested, returned} instead of a silent success.

sessions / clearSessions manage the warm authenticated sessions the backend reuses to skip login (see Session reuse). Session contents are never returned — a session cookie is a bearer credential. clearSessions marks sessions invalid rather than deleting the rows, so reuse stops immediately while the capture history stays readable.

test_suite

test_case

executions

404 from the backend surfaces as isError: true with {error: 'NotFound', message, uuid}. Credentials are always returned without passwords.

Pagination

Every list response is paginated. Response shape:

{
  "pageInfo": { "page": 1, "pageSize": 20, "totalCount": 47, "totalPages": 3, "hasMore": true },
  "<items>": [ ... ]
}

Pass optional page (1-indexed, default 1) and pageSize (default 20, max 200; oversized values are clamped). No response is ever silently truncated.

A get returns the one object under its singular name — {project}, {execution}, {project, environment} — with no pageInfo.

Resources

Alongside tools, the server exposes the read-only entities as MCP resources so clients can browse and @-mention them as context:

Reads dispatch to the same handlers as the project / environment / executions tools, so the data and auth are identical. Resources are additive — clients without resource support keep using the tools.

Security invariants

• Passwords are write-only. They never appear in any response body from any tool.

• Tunnel URLs (*.tunnel.debugg.ai, and the retired *.ngrok.debugg.ai that historical runs still reference) are stripped from all browser-agent responses, including agent-authored text.

• 404s from the backend surface as isError: true with {error: 'NotFound', ...}, never as thrown exceptions.

• Missing DEBUGGAI_API_KEY surfaces as a structured tool error on first invocation — the server still registers and lists tools normally.

Migration to v6.0.0 (backend verdicts, no MCP-authored text)

A run verdict is pass | fail | error, with the backend's reason relayed verbatim. A run that never attempted a test reads outcome: null, skipped: true, skipReason.

Full list: CHANGELOG.md 6.0.0.

Migration to v3.0.0 (action-based tools)

v3 consolidated the 20 per-verb tools into 8 action-based tools. Old tool → new tool {action}:

delete actions now require confirmation (elicitation prompt, or confirm: true). Clients pick up the new surface on MCP restart.

Migration from v1.x (breaking change in v2.0.0)

v2 collapsed a 22-tool surface to 11. Old-tool → new-tool mapping:

Response-shape changes: the bare count field on list responses is gone — use pageInfo.totalCount.

Configuration

DEBUGGAI_API_KEY=your_api_key

Remote / HTTP transport (optional)

By default the server speaks stdio (local npx). It can instead run as a hosted, multi-user remote MCP over stateless Streamable HTTP + OAuth:

DEBUGGAI_MCP_TRANSPORT=http PORT=3000 DEBUGGAI_TOKEN_TYPE=bearer npx -y @debugg-ai/debugg-ai-mcp@latest

It is an OAuth Resource Server: every POST /mcp needs Authorization: Bearer <token>; missing/invalid tokens get a 401 with a WWW-Authenticate pointing at the RFC 9728 metadata, and clients run the OAuth flow against the advertised authorization server. The bearer is request-scoped — api.debugg.ai validates it.

stdio installs need none of these.

Multi-replica deployments (go/no-go before rollout): tunnel state (the session tunnel, its Caddy instance, and its port-route lock) is in-process, keyed per caller by a hash of the bearer token — there is no cross-process coordination. Running several replicas behind a plain round-robin load balancer means one caller's calls can land on different replicas and mint one tunnel per replica they hit instead of one for the whole session (bounded by replica count, self-healing via the existing 55-minute idle auto-shutoff — never a cross-session correctness bug, since any single tool call stays on one replica for its whole duration). To get the intended "one tunnel per session" behavior on a multi-replica HTTP deployment, configure session-affine routing at the load balancer (sticky/consistent-hash keyed on the same identity getSessionKey() derives — in practice, the caller's Authorization bearer token). See docs/local-tunnel-multiplexer-architecture-2026-07-31.md §2.1 for the full reasoning and the honest degrade path if this isn't configured.

Telemetry

The MCP server ships with telemetry enabled by default — an embedded write-only PostHog project key (phc_*) so the team can observe cache hit rates, poll cadence, tunnel reliability, and other operational metrics across the install base. Captured events:

Privacy posture:

• The distinct ID is SHA-256(api_key).slice(0, 16) — never the raw key, no PII.

• phc_* keys are write-only by PostHog convention; safe to embed in source.

• Set DEBUGGAI_TELEMETRY_DISABLED=1 to opt out entirely (resolves to a no-op provider; no events leave the process).

The active mode is logged at boot:

Telemetry enabled (PostHog, DebuggAI default project). Set DEBUGGAI_TELEMETRY_DISABLED=1 to opt out.
Telemetry enabled (PostHog, custom POSTHOG_API_KEY)
Telemetry disabled (DEBUGGAI_TELEMETRY_DISABLED is set)

Local Development

npm install
npm run build
npm run test:e2e        # real end-to-end evals against the backend

The eval suite spawns the built MCP server as a subprocess, exercises every tool against a real backend, and writes per-flow artifacts to scripts/evals/artifacts/<timestamp>/. See scripts/evals/flows/ for the individual scenarios.

MCP registration: debugg-ai-local vs debugg-ai

This repo ships a .mcp.json that registers a project-scoped server named debugg-ai-local pointing at node dist/index.js — the freshly-built local code. It only activates when Claude Code's working directory is this repo.

Your other projects should use the user-scoped debugg-ai registration that pulls from the published npm package:

npm run mcp:global      # registers debugg-ai in ~/.claude.json to npx -y @debugg-ai/debugg-ai-mcp

After editing code here, run npm run mcp:local (which just rebuilds) so the next invocation of debugg-ai-local picks up your changes.

Links

Dashboard · Docs · Issues · Discord

Apache-2.0 License © 2025 DebuggAI