Argus QA MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ARGUS_RECORD | No | Set to true to record every session automatically; saved when the client disconnects. | false |
| ARGUS_EMAIL_TO | No | Comma-separated recipients of every report, e.g. client@acme.com,qa@yourco.com. Off by default. | |
| ARGUS_HEADLESS | No | Set to false to show the browser window. | true |
| ARGUS_SMTP_HOST | No | Your SMTP server host. | |
| ARGUS_SMTP_PASS | No | SMTP login password. | |
| ARGUS_SMTP_PORT | No | Your SMTP server port. | 587 |
| ARGUS_SMTP_USER | No | SMTP login username. | |
| ARGUS_EMAIL_FROM | No | Sender address. | ARGUS_SMTP_USER |
| ARGUS_SMTP_SECURE | No | Implicit TLS. Otherwise STARTTLS is required, except to localhost. | true on port 465 |
| ARGUS_EMAIL_MAX_MB | No | Size limit for the email; videos that don't fit are left out. | 20 |
| ARGUS_ALLOWED_HOSTS | No | Comma-separated hosts the agent may open as pages, e.g. staging.myapp.com,localhost. Subdomains included. Defaults to any host. | |
| ARGUS_NOTIFY_WEBHOOK | No | URL notified when an assessment finishes: a Slack or Discord incoming webhook, or any endpoint that accepts JSON. Off by default. | |
| ARGUS_RECORDINGS_DIR | No | Where recordings are written. | ~/argus-qa/recordings |
| ARGUS_SCREENSHOT_DIR | No | Where screenshots are written. | ~/argus-qa/screenshots |
| ARGUS_BROWSER_CHANNEL | No | Use an installed browser channel such as chrome or msedge; defaults to bundled Chromium. | |
| ARGUS_EMAIL_ATTACH_VIDEO | No | Attach the screen recording when it fits. | true |
| ARGUS_EMAIL_WAIT_SECONDS | No | How long to wait for the agent's suggested fixes before emailing anyway. 0 sends at once. | 180 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| navigate_urlA | Navigate the active browser page to a URL. Returns the HTTP status code, final URL and page title. Resets the console and network logs. |
| get_page_snapshotA | Return the page's accessibility tree as YAML: roles, accessible names, values and states, including iframe contents. Every element has a [ref=eN] handle; pass it to other tools as selector "aria-ref=eN". Use this before interacting with a page instead of guessing selectors. Refs from older snapshots may go stale. |
| click_elementA | Click the first element matching a selector. Waits for any navigation the click triggers. Note "text=" is a case-insensitive substring match against any element (headings included); prefer aria-ref from get_page_snapshot or scoped selectors like button:has-text("Login"). |
| fill_inputA | Clear an input, textarea or contenteditable element and fill it with text. Values typed into password and payment-card fields are masked in recordings. Card fields are refused if the page uses a LIVE payment environment; use the provider's test mode and test cards (e.g. Stripe 4242 4242 4242 4242). |
| select_optionB | Choose option(s) in a element, matching each by its value or its visible label. |
| press_keyA | Press a key or chord, e.g. "Enter", "Tab", "Escape", "ArrowDown", "Control+A". Focuses the element first when a selector is given, otherwise sends it to whatever has focus. Waits for any navigation it triggers. |
| hover_elementA | Move the mouse over an element, e.g. to open a dropdown menu or reveal a tooltip. |
| wait_forA | Wait until an element (by selector) or a piece of visible text reaches a state: visible (default), hidden, attached or detached. Useful after actions that load content asynchronously. |
| take_screenshotA | Capture a PNG of the current page (full scrollable page or just the viewport) and save it to the screenshot directory. Returns the file path and, unless returnImage is false or the image is very large, the image itself. |
| assert_textA | Test assertion: PASS if the text is visible on the page (or inside the element matched by selector) within the timeout, otherwise FAIL (isError) with the text that was actually there. |
| assert_visibleA | Test assertion: PASS if the element is visible (or, with visible=false, hidden/absent) within the timeout, otherwise FAIL (isError). |
| get_console_errorsA | Return JavaScript console errors, uncaught exceptions, failed network requests, HTTP >= 400 responses and guard blocks recorded since the last navigate_url. Chrome's duplicate "Failed to load resource" messages are merged into the matching network entry. |
| get_network_requestsA | List HTTP requests made by the page since the last navigate_url: method, URL, resource type, status, duration, failure reason and whether a mock answered it. Static assets are hidden by default. |
| mock_routeA | Intercept browser requests matching a URL glob and answer them with a canned response, an error, or a delay, without contacting the real server. Tests UI behavior for API errors, payment declines, timeouts and outages. Only the browser sees the mock; no backend is contacted. Mocks persist until clear_mocks. |
| clear_mocksA | Remove one mock by id, or all mocks when no id is given. Returns the mocks still active and their hit counts. |
| start_recordingA | Start recording the browser session for later review by a developer: a Playwright trace (DOM snapshots, network, console for every step), an optional video, and a log of every tool call. With video on, the page is reloaded into a fresh recording context (cookies and localStorage are kept). Call stop_recording when done to save everything. |
| stop_recordingA | Stop the active recording and save its trace.zip, video, screenshots, actions.json and an HTML report. Returns the overall verdict, the failed checks and errored steps with explanations, the number of website errors, the file paths and the command to open the trace viewer. If anything failed, follow up with suggest_fix for each failed step. When email delivery is configured, the report is emailed to the configured recipients once every failure has a suggested fix (see delivery in the result). |
| suggest_fixA | Add your suggested fix for a failed step to the recording's report, shown in the "AI agent's suggested fix" column. Use the step numbers from stop_recording (failedChecks / toolErrors) or from failed tool calls during the recording. Diagnose the actual cause from the evidence (error explanation, actual page text, screenshot, console and network errors) and give a concrete fix: name the selector, file, endpoint or setting to change. Say whether the fix belongs in the app (a real bug), the test (wrong selector or expectation) or the environment (server down, missing data). Works during a recording or after stop_recording; calling it again for a step replaces the earlier suggestion. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools have clearly distinct purposes across navigation, interaction, assertions, diagnostics, mocking, and recording. Minor overlap exists between wait_for and the assert_* tools, and between get_console_errors and get_network_requests since both surface failed network activity, but descriptions clarify the intended use.
All tool names consistently use snake_case with a verb-led pattern such as navigate_url, click_element, assert_visible, mock_route, and start_recording. There are no mixed naming conventions or confusing style deviations.
The 18 tools cover a broad browser-automation and QA workflow, and each has a distinct role. The count is slightly above the typical 3-15 range but remains reasonable for a server combining page interaction, assertions, diagnostics, mocking, and recording.
The surface covers essential browser automation and QA lifecycle operations: navigation, snapshots, interactions, assertions, console/network diagnostics, mocking, and recording with suggested fixes. Some gaps remain, such as file upload, drag-and-drop, and explicit tab/window or storage management, but agents can work around most of these.