Debugg AI MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEBUGGAI_API_KEY | Yes | Your Debugg AI API key, required for authentication. | |
| DEBUGGAI_API_URL | No | Override API endpoint (defaults to https://api.debugg.ai). | https://api.debugg.ai |
| DEBUGGAI_LOCAL_PORT | No | Your app's local port (e.g., 3000). | |
| DEBUGGAI_LOCAL_REPO_NAME | No | GitHub repo name (e.g., your-org/repo). | |
| DEBUGGAI_LOCAL_REPO_PATH | No | Absolute path to the project root. | |
| DEBUGGAI_LOCAL_BRANCH_NAME | No | The name of the current branch (e.g., main). |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| resources | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_app_in_browserA | Give an AI agent eyes on a live website or app. The agent browses it, interacts with it, and tells you whether a given task or check passed. Works on localhost or any URL. Use for visual QA, flow validation, regression checks, or anything that needs a real browser to verify. LOCALHOST SUPPORT: Pass any localhost URL (e.g. http://localhost:3000) and it Just Works. A secure tunnel is automatically created so the remote browser can reach your local dev server — no manual ngrok setup, no port forwarding, no config. SCOPE PER CALL: Keep each call to ONE focused check — a single page or a short interaction on a single screen (login, submit a form, verify a heading). For anything spanning multiple pages or long multi-step flows, split into SEPARATE calls — the remote browser agent has a ~25-step internal budget per call, and long single calls risk client-side timeouts. Example: instead of "log in, then go to settings, then update profile, then verify," make three calls: (1) log in & verify dashboard, (2) update settings, (3) verify profile change. |
| probe_pageA | Probe one or more URLs and return their rendered state — screenshot, page metadata (title/finalUrl/statusCode/loadTimeMs), structured console errors, and per-URL network summary (refetch loops collapse into one row by origin+pathname). WHEN TO USE: "did I just break /settings?" / "smoke-test these 5 routes after my refactor" / "what's actually rendering at /dashboard?" — fast (<10s for 1 URL, <25s for 20), no LLM cost, no agent loop. NOT FOR: scenario verification (sign in → click X → assert Y), interaction (clicks, form fills, scrolls), or anything requiring agent decisions. Use check_app_in_browser for those. LOCALHOST SUPPORT: any localhost URL is auto-tunneled. Pre-flight TCP probe fails fast (<2s) if the dev server isn't listening. BATCH MODE: pass up to 20 targets in one call to share browser session + tunnel — dramatically faster than firing parallel single-URL probes (one execution unit, not N). Per-URL waitForSelector / waitForLoadState / timeoutMs override defaults. A single failed target's error appears in result.error without failing the whole batch — the other results stay valid. |
| trigger_crawlA | Trigger a browser-agent crawl of a web app to build the project's knowledge graph. The crawl systematically explores pages, UI states, and navigation flows, then populates the backend's knowledge graph so future evaluations and tests have context about the app. LOCALHOST SUPPORT: Pass any localhost URL (e.g. http://localhost:3000) and it Just Works. A secure tunnel is automatically created so the remote browser can reach your local dev server. WHEN TO USE: after a significant new feature, a new environment, or when onboarding a project. NOT for per-change verification — use check_app_in_browser for that. SCOPE: one crawl per call against one URL. The crawl is long-running (minutes to tens of minutes depending on app size) and populates backend state asynchronously; the tool returns the execution status once the workflow completes. This does NOT return pass/fail — it returns executionId + status + outcome. |
| projectA | Manage DebuggAI projects. Pass an "action":
Note: there is no update/delete here — rename/delete a project from the DebuggAI web app. |
| environmentA | Manage environments (and their login credentials) under a project. Pass an "action":
|
| test_suiteA | Manage and run test suites. Identify a suite by suiteUuid, or suiteName + a project identifier (projectUuid|projectName). Pass an "action":
|
| test_caseA | Manage individual test cases within a suite. Pass an "action":
|
| executionsA | Look up workflow executions (history of check_app_in_browser, trigger_crawl, and test-suite runs). Pass an "action":
Tip: after a fresh check_app_in_browser run, poll action:"get" with the returned executionId until artifact URLs are available. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| projects | All projects visible to this API key (first page). |
| environments | Environments for the auto-detected project (credentials redacted). |
| executions | Recent workflow executions (first page). |
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/debugg-ai/debugg-ai-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server