🧪 Official MCP Server for Debugg AI

What is 🧪 Official MCP Server for Debugg AI?

The 🧪 Official MCP Server for Debugg AI is an MCP server that provides AI-powered browser testing. Point it at any URL (including localhost), describe what to test in natural language, and an AI agent browses the application, returning pass/fail results with screenshots. It is intended for developers and QA teams who want automated, AI-driven browser testing through MCP clients.

How to use 🧪 Official MCP Server for Debugg AI?

Requires Node.js 20.20.0 or later and an API key from debugg.ai. Add the server configuration to your MCP client’s settings, using npx -y @debugg-ai/debugg-ai-mcp and the environment variable DEBUGGAI_API_KEY. Alternatively, run with Docker: docker run -i --rm --init -e DEBUGGAI_API_KEY=your_api_key quinnosha/debugg-ai-mcp. After setup, invoke tools like check_app_in_browser with natural language instructions.

Key features of 🧪 Official MCP Server for Debugg AI

• Eight tools: three Browser tools and five action-based tools.
• AI agent (check_app_in_browser) navigates, interacts, and returns screenshots.
• Lightweight probe_page tool (no LLM) for batch URL checks.
• trigger_crawl populates a project’s knowledge graph.
• Action-based tools for project, environment, test suite, test case, and execution management.
• Auto-tunneling of localhost URLs via ngrok.
• Returns HAR (network trace) and console logs for each browser session.
• Read-only resources via debugg-ai:// URIs.

Use cases of 🧪 Official MCP Server for Debugg AI

• Automated end‑to‑end testing of web applications from an MCP client.
• Quick smoke tests across multiple routes after a refactor using probe_page.
• Detecting refetch loops and hydration errors via captured HAR and console logs.
• Pre‑populating a project’s knowledge graph with trigger_crawl.
• Running suites of test cases defined in the Debugg AI platform.

FAQ from 🧪 Official MCP Server for Debugg AI

What is the difference between check_app_in_browser and probe_page?

check_app_in_browser uses an AI agent (LLM) that navigates and interacts with the page, returning a pass/fail verdict with screenshots. probe_page is a lightweight, no‑LLM batch probe that captures rendered state (screenshot, console errors, network summary) for up to 20 URLs without scenario assertions.

How is authentication handled?

The server requires a DEBUGGAI_API_KEY environment variable set to an API key obtained from debugg.ai. The key is never exposed in tool responses. Missing keys surface as a structured tool error on the first invocation.

What runtime dependencies are needed?

The server requires Node.js version 20.20.0 or later (transitive requirement from posthog-node). It runs as a stdio MCP server, invoked via npx or Docker.

Where are browser session artifacts (HAR, console logs) stored?

Artifacts are uploaded to AWS S3 as presigned URLs. The URLs are short‑lived; they can be renewed by refetching the parent execution via the executions tool with action get and the execution UUID. Sensitive headers (Authorization, Cookie, token/secret/api_key) are scrubbed server‑side before persistence.

What are the known limits of the AI agent?

check_app_in_browser has an internal budget of approximately 25 steps per call. For broader test scenarios, split them across multiple calls. The probe_page tool accepts 1–20 URLs with a total performance budget of under 10