This server lets you run AI-powered automated QA audits on web pages:
argus_audit — Quick QA Pass: Fast audit checking for JS errors, network failures, accessibility issues, SEO problems, security vulnerabilities, CSS issues, and content quality. Optionally mark routes as critical to escalate console errors.
argus_audit_full — Deep QA Pass: Comprehensive audit including everything in the quick pass, plus Lighthouse scoring (performance, accessibility, SEO, best practices), responsive layout checks across 4 viewports (375px, 768px, 1024px, 1440px), memory leak detection via V8 heap snapshots, hover-state bug detection, and accessibility tree snapshot analysis.
argus_compare — Environment Diff: Compare two environments (e.g., dev vs. staging) side-by-side — captures screenshots, runs the full analyzer suite on both, and diffs findings to identify regressions or severity changes. Falls back to detailed CSS analysis if no staging URL is configured.
argus_last_report — Retrieve Last Report: Fetch the most recently saved Argus JSON report from the reports/ directory, useful for reviewing previous results without re-running an audit.
Sends rich audit reports to Slack channels, with issue severity classification and routing.
One line in your MCP config gives Claude (or any MCP agent) a real Chrome audit engine — 67 audit categories · 149 finding types · zero test files to write or maintain. And with Aegis, what it finds never leaks your secrets to the LLM.
▶ See it in action → argus-qa.com
Quick Start · The Fix Loop · What It Catches · Your Stack · MCP Tools · Full Setup · Reference
AI agents now write most of the code — and they judge their own work by whether it compiles and looks done, not by what actually happens in the browser. The uncaught exception on the third click. The form that posts credentials over HTTP. The 4-second LCP. The button that vanished in dark mode. The API endpoint hammered in an infinite loop.
Argus closes that gap. It drives a real Chrome (via the Chrome DevTools Protocol) against your locally-running app and hands the agent — or you — a structured, severity-ranked bug report. The agent fixes; Argus re-checks; the loop closes before the code leaves your machine.
🧪 No test files, ever | Argus audits the rendered app — DOM, console, network, pixels — not your source. Nothing to write, nothing to maintain when the agent refactors |
🤖 Built for the agent loop | The only QA engine Claude can call natively over MCP. Audit → fix → re-audit without leaving the conversation |
🔒 Safe for agents by default | Aegis: findings are redacted at every egress boundary — secrets, PII, and exploit detail never reach the LLM's context window (OWASP LLM02, default-ON, fail-closed) |
🧰 Also a normal QA tool | CLI batch audits, a GitHub Action PR gate, Slack reports with screenshots, dev-vs-staging diffs, watch mode — with or without an agent |
Related MCP server: AutoSpectra MCP Server
No install.
npxfetches Argus on first run.
1 — Add two lines to .mcp.json in your project root:
{
"mcpServers": {
"chrome-devtools": { "command": "npx", "args": ["-y", "chrome-devtools-mcp@latest"] },
"argus": { "command": "npx", "args": ["-y", "argusqa-os"] }
}
}Or via the Claude Code CLI:
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest
claude mcp add argus -- npx -y argusqa-os2 — Launch Chrome (auto-detects your Chrome, sets the right flags):
npx -y -p argusqa-os argus-chrome# macOS
open -a "Google Chrome" --args --remote-debugging-port=9222 --headless=new
# Windows (PowerShell)
& "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --headless=new --no-sandbox --disable-gpu --user-data-dir="$env:TEMP\chrome-argus"
# Linux
google-chrome --remote-debugging-port=9222 --headless=new --no-sandbox3 — Ask your agent:
Run argus_audit on http://localhost:3000That's it. Findings come back structured and severity-ranked — into the conversation, to Slack, or as a local report.html. Something off? npx -y -p argusqa-os argus-doctor diagnoses your setup in one command.
This is what Argus looks like inside an agentic coding session:
You: Build me a checkout page with a card form.
Agent: [writes the code, dev server renders it]
You: Run argus_audit on http://localhost:3000/checkout
Argus: ● 2 critical · 3 warnings
● uncaught TypeError in checkout.js (visible on submit)
● form posts over HTTP — security_no_https
▲ card inputs missing labels + autocomplete (a11y/WCAG)
▲ LCP 4.1s — hero image unoptimized
▲ duplicate POST /api/cart ×7 — likely render loop
Agent: [fixes all five]
You: Run argus_get_context
Argus: ✓ resolved: 5 · persisting: 0 · new: 0argus_get_context diffs against the previous snapshot, so the agent knows exactly what it fixed, what it broke, and what remains — no re-reading walls of output.
"But my agent can already drive a browser…" — it can. Driving isn't judging. A raw browser MCP (Playwright MCP, bare chrome-devtools-mcp) gives the agent hands and eyes; the agent must then re-derive what to check every session, burning context on console-log spelunking. Argus is the judgment layer on top: 149 codified finding types with thresholds, severity policy, cross-run baselines, flakiness filtering, dedup, root-cause hints — returned in one call, redacted by default.
32 analysis engines, 149 distinct issue types, zero test-file maintenance:
Category | What it detects |
JavaScript | Uncaught exceptions, unhandled promise rejections, |
Network & API | HTTP 5xx, 401/403 auth failures, duplicate API calls (infinite loops), 4xx errors, broken links |
Performance | LCP > 2500ms, CLS > 0.1, TTFB > 800ms, slow APIs > 1s/3s, payloads > 500KB/2MB, JS bundles > 500KB |
Accessibility | axe-core (80+ WCAG rules), color-blind simulation, missing ARIA, keyboard focus, heading hierarchy |
SEO | Missing meta description, OG tags, canonical, viewport, h1 |
Security | Auth tokens in localStorage/URL, |
CSS | Cascade overrides, component style leaks, unused rules, React inline style conflicts |
Content |
|
Responsive | Horizontal overflow at 375px/768px, touch targets < 44×44px |
Memory | Detached DOM nodes via V8 heap snapshot, heap growth across navigation |
Visual | Pixel-level screenshot regression via pixelmatch (≥0.1% warning, ≥5% critical) |
Figma | Design-to-implementation fidelity — 13 property types (color, spacing, typography, shadows, etc.) |
Forms | Missing |
Fonts | FOIT, FOUT, missing fallbacks, slow loads > 1s, suboptimal formats |
Motion |
|
Theme | Dark-mode gaps — static CSS vars, missing |
Network baseline | New requests, missing requests, status-code regressions vs saved HAR baseline |
Environment diff | Dev vs staging — screenshot diff, DOM changes, console/network regressions |
And every finding is post-processed with:
Post-processor | What it adds |
Intelligent baseline filtering | Findings that flip-flop across runs are tagged |
Root cause linking | New findings are annotated with the recent git commits and files most likely to have caused them ( |
All findings are classified as
critical/warning/infoand routed to the right Slack channel — or surfaced in the local HTML report. For per-finding severity tables and detection methods, see REFERENCE.md.
Argus audits the rendered output, not your source — so it is framework-agnostic by construction. If it runs in Chrome, Argus can audit it:
SPA frameworks | React, Vue, Angular, Svelte/SvelteKit, Solid, Preact, Astro… |
Meta-frameworks | Next.js, Nuxt, Remix, Gatsby — plus framework-aware extras: Next.js & React Router route discovery, import-graph PR mapping ("this component changed → audit only the routes that render it"), monorepo path awareness |
Server-rendered | Rails, Django, Laravel, Flask, Spring, PHP — anything that serves HTML to a browser |
Static / no framework | Plain HTML/CSS/JS, docs sites, landing pages |
APIs (via the page) | Response schema validation, status/timing checks on every request the page makes |
Honest limits: Chrome/Chromium rendering only (no Safari/Firefox engine differences), web only (no native mobile/desktop apps), and backend services are checked through the traffic the page generates — not as standalone API test suites.
Default ON. Argus audits your app for secrets and vulnerabilities — so its findings are exactly the data you least want leaving your machine. Aegis redacts them at every external boundary before they cross. For teams adopting AI agents, this is the difference between "we use an AI QA tool" and "we can tell our security lead exactly why it's safe."
A finding sent to an external sink — an MCP tool response (which lands in the calling agent's context window and transits to that agent's model provider), a Slack message, a GitHub PR comment + its ::error annotations, the hosted/CI HTML report, or CI logs — is reduced to a need-to-know projection: a sensitive finding crosses as its type + route + severity + a 🔒 marker, and never its raw payload (message, evidence, request/response bodies, headers, cookies, stack). URLs are projected with the query string stripped (tokens hide there). A benign finding keeps its message — but that message is still scrubbed for any accidentally-embedded secret or PII.
Principle | Behavior |
Local fidelity preserved | The on-disk JSON report and the locally-opened HTML keep 100% detail — redaction only removes detail on the way out |
Fail-closed | On any classifier error or unknown finding shape, Aegis redacts more, never less |
Deny-by-default | Only an explicit allowlist of safe fields ever crosses; a new field leaks nothing until deliberately allowlisted |
5-layer detection | Category rules ∪ 13 secret regexes ∪ statistical rarity (entropy / token-efficiency) ∪ 7 Luhn-validated PII rules ∪ context boosting |
Opt-out |
|
This implements the OWASP LLM02:2025 — Sensitive Information Disclosure mitigations (data minimization, redaction, deny-by-default egress filtering) at Argus's own boundaries. An optional, local-only re-hydration vault (ARGUS_REDACT_VAULT=1) can mint reversible, information-free tokens for diff-stable artifacts — re-inflate locally with npm run report:rehydrate. Full behavior change is documented in CHANGELOG.md.
Ask Claude (or any MCP client) — no terminal required:
Tool | Description |
| Fast pass — JS, network, accessibility, SEO, security, CSS, content |
| Deep pass — adds Lighthouse, responsive checks, memory leak detection, hover-state bugs |
| Diff dev vs staging — screenshots, findings delta, environment regressions |
| Capture everything broken on the open tab — with |
| Snapshot the open tab without navigating (preserves auth/form state) |
| Return last JSON report without re-running |
| Figma URL → 13 design-token finding types (color, spacing, typography, shadows, etc.) |
| Screenshot baseline comparison. Pass |
| Fetch GitHub PR diff → map changed files to affected routes → targeted audit → baseline-aware block decision (blocks on findings the PR introduces) + idempotent PR comment + Check Run → |
Every tool response is projected through the Aegis egress boundary before it reaches the agent, and carries an optional
redactionrider ({ redacted, total }) when sensitive detail was withheld.
Example prompts:
Run argus_audit on http://localhost:3000/checkout
Run argus_audit_full on http://localhost:3000/dashboard
Run argus_compare
Run argus_get_contextArgus's own correctness is enforced the way it audits yours:
998/998 hard assertions across a 171-block integration harness driving real Chrome against 64 fixture pages — including per-category negative controls (zero over-fire), golden response schemas for all 9 MCP tools, and an upstream-drift canary that catches chrome-devtools-mcp API changes at version-bump time
562 Chrome-free unit tests (Vitest) + property-based parser fuzzing
npm audit: 0 vulnerabilities · CodeQL + Dependabot on every PR · Socket.dev: 100/100/100 on vulnerability/quality/license
Session files and captured tokens written 0600, owner-only
Requirement | Version |
Node.js | v20.19+ |
Chrome | Stable (desktop or headless) |
Claude Code | Latest ( |
Slack workspace | Optional — omit for local |
No local install needed. Use the Quick Start above, then add your target URL:
# .env in your project root
TARGET_DEV_URL=http://localhost:3000
TARGET_STAGING_URL=https://staging.example.com # optional — enables argus_compareOptional — Slack notifications:
api.slack.com/apps → Create New App → name it BugBot
OAuth & Permissions → Bot Token Scopes: chat:write, files:write, files:read
Install to workspace → copy the xoxb-... token
Create channels #bugs-critical, #bugs-warnings, #bugs-digest and run /invite @BugBot in each
SLACK_BOT_TOKEN=xoxb-...
SLACK_CHANNEL_CRITICAL=C0000000000
SLACK_CHANNEL_WARNINGS=C0000000001
SLACK_CHANNEL_DIGEST=C0000000002Without Slack: Argus auto-generates
reports/report.htmland opens it in your browser — zero extra config.
npm install --save-dev argusqa-os
npx argus init # interactive wizard — detects framework, discovers routes, writes .env
npm run crawl # run after Chrome is startedgit clone https://github.com/ironclawdevs27/Argus.git
cd Argus
npm install
npm run init # interactive setup wizardManual setup (skip the wizard):
cp .env.example .env
# Fill in TARGET_DEV_URL and optional Slack tokensThen configure your routes in src/config/targets.js:
export const routes = [
{ path: '/', name: 'Home', critical: true, waitFor: 'main' },
{ path: '/login', name: 'Login', critical: true, waitFor: 'form' },
{ path: '/dashboard', name: 'Dashboard', critical: true, waitFor: '[data-testid="dashboard"]' },
{ path: '/settings', name: 'Settings', critical: false, waitFor: null },
];critical: true — errors on this route go to #bugs-critical
waitFor — CSS selector Argus waits for before capturing (signals page-ready)
npm run chrome # Launch Chrome with --remote-debugging-port=9222 (auto-detects binary)
npm run doctor # Pre-flight check: Chrome reachable, .mcp.json valid, .env has TARGET_DEV_URL
npm run crawl # Batch audit of all configured routes
npm run compare # Dev vs staging diff (CSS-only if no staging URL)
npm run watch # Passive monitor — polls open Chrome tab every 1s
npm run report:html # Generate reports/report.html from last JSON audit
npm run report:pdf # Export HTML report to A4 PDF (requires: npm install puppeteer)
npm run server # Start Slack slash-command server (port 3001)
npm run init # Interactive setup wizard
npm run test:unit # 562 unit tests — no Chrome required
npm run test:harness # 171-block correctness harness — requires Chrome
npm run test:harness:log # same, but tees full output to harness-results.txt
npm run test:coverage # merged unit + harness coverage gate (requires Chrome)Watch mode — live monitoring as you (or your agent) develop:
# Terminal 1: start your app
npm run dev
# Terminal 2: start Argus watcher
npm run watch
# Ctrl+C → stops monitor and writes reports/report.htmlSlack slash command (on-demand from any channel):
/argus-retest https://staging.example.com/checkoutTo expose the server via tunnel: cloudflared tunnel --url http://localhost:3001 (free, no account required). Set the resulting URL as the Request URL in Slack App → Slash Commands.
Argus ships as a composite GitHub Action: on every PR it maps the diff to affected routes, audits them, and blocks the merge only on findings the PR introduces (baseline-aware) — with an idempotent PR comment and a Check Run.
Add to your repo's secrets (Settings → Secrets → Actions):
Secret | Required | Value |
| Yes | Your staging base URL |
| No |
|
| No* | Channel ID (needed when Slack is configured) |
| No* | Channel ID |
| No* | Channel ID |
| No | Auto-injected by Actions for PR comments + Check Runs |
The included workflow runs on push to main, daily at 6 AM UTC, and on manual trigger. If critical issues are found, the pipeline fails.
Variable | Default | Description |
| — | Required. Base URL of your dev environment |
| — | Staging URL — enables |
| — |
|
| — | For |
| — | Channel ID for critical bugs |
| — | Channel ID for warnings |
| — | Channel ID for info / daily digest |
|
| Slack slash-command server port |
|
| Where to write JSON reports |
|
| Parallel MCP clients for route crawling |
|
|
|
| — | Set |
|
| Max retries for |
|
| Watch mode poll interval (ms) |
|
| Watch mode web dashboard port |
| — | App source path — enables env-var / feature-flag / dead-route analysis and framework-aware PR route mapping (import-graph: a changed component/stylesheet → only the routes that render it) |
| — | Path to app |
|
| Pixel diff % threshold for environment comparison |
| — | For PR comments + Check Runs |
| — |
|
| — | Auto-injected by Actions from PR context |
|
| New criticals before blocking merge (0 = never block) |
| — | Visual diff image URL to embed in PR comment |
| — | OTLP collector for Jaeger / Grafana Tempo |
| — | Required for |
|
| Slow web font load threshold (ms) |
|
| WCAG AA min contrast ratio for CVD simulation |
|
| Aegis egress redaction. |
|
| Matched-span style: |
| off local / ON in CI |
|
|
|
|
First stop for anything broken:
npx -y -p argusqa-os argus-doctor— it checks Chrome reachability, MCP config validity, and required env keys, and prints the exact fix for each failure.
Chrome DevTools MCP not connecting
claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest
# Restart Claude Code after addingSlack messages not posting
Token must start with xoxb- (not xoxp-, xoxe-, or xapp-)
Run /invite @BugBot in each channel
Required scopes: chat:write, files:write, files:read
Screenshots are blank
Page hasn't settled — increase pageSettleMs in src/config/targets.js or add a waitFor selector for the route
/argus-retest returns "dispatch_failed"
Tunnel URL changed — update the Request URL in Slack App → Slash Commands and reinstall
CSS analysis returns empty results
Page may be behind auth — ensure you're logged in on the Chrome instance Argus is controlling
CI pipeline fails immediately
Chrome may not start fast enough — increase sleep 3 to sleep 5 in .github/workflows/argus.yml
Argus is a complementary layer, not a replacement for unit or E2E tests:
Playwright / Cypress | Raw browser MCP (Playwright MCP, chrome-devtools-mcp) | Argus | |
Purpose | Test your logic and API contracts | Give an agent browser hands & eyes | Give the agent (and you) judgment about what's broken |
What you get | Pass / fail on scripts you wrote | Raw DOM/console/network access | 149 codified finding types, severities, baselines, noise filtering, root-cause hints |
Maintenance | Test files, forever | Re-prompt the checks every session | Zero — audits the rendered app |
When it runs | In your test suite | When the agent thinks to look | On demand, in CI as a PR gate, or continuously (watch mode) |
Output | Pass / fail | Whatever the agent noticed | Structured reports with screenshots — Slack, HTML, PR comments — secrets redacted |
All 998 harness assertions pass (998/998) — there are currently no known MCP- or Chrome-layer restrictions. Lighthouse runs headless (after the lighthouse_audit argument fix); the remaining soft assertions (perf traces, GC-dependent heap-growth) are promoted to counted hard assertions only in the weekly strict-soft lane (harness-strict.yml) via ARGUS_HARNESS_STRICT_SOFT. Scope limits: Chrome/Chromium only, web apps only — see Works With Your Stack.
Want audits without running Chrome or npm — with history, trends, schedules, and a team dashboard? Argus Cloud is in founding-member early access: $19/month, locked forever (regular $29).
Become a founding member → argus-qa.com
The open-source engine on this page stays MIT and fully-featured, always — the hosted tier sells convenience and memory, never detections.
src/
argus.js — single-page audit entry point
mcp-server.js — 9 MCP tools exposed to Claude / any MCP client
orchestration/ — crawl loop, Slack/GitHub dispatch, env comparison, watch mode
utils/ — 32 analysis engines (accessibility, security, performance, PDF, recording, etc.)
adapters/browser.js — CdpBrowserAdapter — wraps all chrome-devtools-mcp calls
config/targets.js — routes, thresholds, auth steps
cli/
init.js — argus init interactive setup wizard
chrome-launcher.js — npm run chrome / argus-chrome — launches Chrome with correct flags
doctor.js — npm run doctor / argus-doctor — pre-flight checks
pr-validate.js — headless CI entry point for GitHub Actions
test-harness/ — 171-block correctness harness, 998 hard assertions, 64 fixture pages
test/unit/ — 562 Vitest unit tests (no Chrome required)
landing/ — Product landing page (React 19 + Vite + Tailwind)Full source map → CLAUDE.md · MCP/DSL reference → SKILL.md
Contributions are welcome — fixture pages, new detection categories, framework route-discovery, docs. Start with CONTRIBUTING.md.
Fork the repo and create a branch
npm run test:unit — verify without Chrome (562 tests)
npm run test:harness — full integration coverage (requires Chrome on port 9222)
Open a PR — Argus audits itself via the CI workflow
MIT © ironclawdevs27
Argus Panoptes — the all-seeing giant of Greek mythology who never slept.
Fast QA audit on a URL via Chrome DevTools Protocol. One-pass detection sweep: JS errors, unhandled rejections, network failures (4xx/5xx), CORS errors, API frequency loops, slow APIs and blocking third-party requests, API contract violations, sync XHR, document.write, long tasks, service worker failures, debugger statements, duplicate IDs, SEO violations, security header checks, content quality, Chrome DevTools Issues panel, and HTTPS enforcement. Returns { findings: [{severity, type, message, url}], summary: {critical, warning, info} }. Use for CI smoke tests and pre-deploy gates. Pass cache: true to skip re-crawl on repeat calls to the same URL within a session — useful in tight fix loops. For Lighthouse scoring, CSS analysis, responsive checks, and memory leak detection, use argus_audit_full. Requires Chrome running with --remote-debugging-port=9222.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to audit, including protocol and path (e.g. http://localhost:3000/checkout). Must be reachable by the running Chrome instance. | |
| cache | No | When true, returns the cached result for this URL if one exists (from a previous argus_audit call in this session) without re-crawling. Use in fix loops to cheaply re-read the last audit while iterating on a fix. Cache is per-session, max 20 entries, LRU eviction. | |
| critical | No | When true, console.error calls are escalated to critical severity. Set true for business-critical routes (login, checkout, dashboard) where any error is a blocker. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the tool's behavior: it performs a one-pass detection sweep, returns findings with severity/type/message/url and a summary, explains cache behavior (per-session, max 20 entries, LRU eviction), details the critical parameter effect, and notes the prerequisite (Chrome with --remote-debugging-port=9222). No behavioral aspects are hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and list of checks. It is somewhat long due to the enumeration, but each sentence adds value. Minor redundancy could be trimmed (e.g., listing 'returns { findings... }' is helpful but partly repeats schema). Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many checks), no output schema, and 3 parameters, the description completely covers what it does, how to use it, what it returns (including structure), prerequisites, and when to avoid it. No gaps remain for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the cache parameter's practical use ('useful in tight fix loops') and the critical parameter's scenario ('Set true for business-critical routes'), which enhances agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a fast QA audit on a URL using Chrome DevTools Protocol, enumerates numerous specific checks, and distinguishes itself from the sibling tool argus_audit_full by explicitly stating what argus_audit_full covers (Lighthouse scoring, CSS analysis, etc.). This provides a specific verb-resource pairing and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use for CI smoke tests and pre-deploy gates'), provides guidance on the cache parameter for tight fix loops, and explicitly names the alternative tool for other use cases ('For Lighthouse scoring... use argus_audit_full'). This meets the highest standard for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep QA audit — extends argus_audit with Lighthouse performance/accessibility scoring, responsive layout checks across 4 viewports (320/768/1280/1920px), memory leak detection via heap snapshot, hover-state regression detection, and accessibility tree snapshot. Returns full JSON report with findings by severity, Lighthouse scores, and layout overflow details. Use when argus_audit passes clean but visual or performance regressions are suspected. Requires Chrome running with --remote-debugging-port=9222.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to audit, including protocol and path (e.g. https://example.com/dashboard). Must be reachable by the running Chrome instance. | |
| critical | No | When true, console.error calls are escalated to critical severity. Set true for business-critical routes (login, checkout, dashboard) where any error is a blocker. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the tool's actions (Lighthouse, responsive, memory, hover, accessibility) and output format. However, it does not explicitly state that it is read-only or if there are side effects like resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph, somewhat dense but all sentences are informative. Could be structured with bullet points for clarity, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the report contents (findings by severity, Lighthouse scores, layout overflow). It covers the complexity of the tool's features without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds context: url must be reachable, critical escalates console.error to critical severity, and suggests when to set critical to true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extends argus_audit with specific additional capabilities (Lighthouse scoring, responsive checks, memory leak detection, etc.) and distinguishes itself from the sibling tool argus_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when argus_audit passes clean but visual or performance regressions are suspected' and mentions the prerequisite 'Requires Chrome running with --remote-debugging-port=9222.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diffs dev vs staging environments side-by-side. Navigates both URLs, captures screenshots, and runs the full analyzer suite on each, then surfaces regressions — findings present in staging but not dev, or with changed severity. Returns { regressions: [{type, devSeverity, stagingSeverity}], screenshots, summary }. Run before promoting a build to staging to catch environment-specific bugs. Set TARGET_DEV_URL and TARGET_STAGING_URL env vars before starting the server; omit TARGET_STAGING_URL to run CSS-analysis-only mode.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes all steps: navigating URLs, capturing screenshots, running analyzer, and returning regressions. Also explains need for env vars and CSS-analysis-only mode when TARGET_STAGING_URL is omitted. No annotations provided, so description carries full burden and does it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is clear and informative but somewhat lengthy. Could be slightly tightened, but still effective. Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multi-step, env vars, no output schema), description fully covers what the tool does, how to set it up, and what it returns. Leaves no important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; baseline is 4. Description adds no parameter info as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it diffs dev vs staging environments, captures screenshots, runs analyzer, and surfaces regressions. Distinguishes from sibling tools like argus_visual_diff by specifying side-by-side comparison and regression detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Run before promoting a build to staging' and explains environment variable setup. Missing explicit when-not-to-use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full design-to-implementation fidelity audit against a Figma frame. 13 mismatch finding types: CSS token values, component presence, fill/text color (RGB delta), typography (fontSize/fontWeight/lineHeight/fontFamily/letterSpacing), Auto Layout padding and gap, border-radius (per-corner), bounding-box overflow, absolute position drift (scroll-corrected x/y, 20px threshold), border stroke (color+weight), box-shadow (offset+blur+spread+color), opacity, and text content. Selector fallback: tries [data-testid], [aria-label], #id, .class per node. Requires FIGMA_API_TOKEN env var and Chrome on --remote-debugging-port=9222. Returns { findings, summary } where summary includes 13 mismatch-type counts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the page to audit (e.g. http://localhost:3000/dashboard). Must be reachable by the running Chrome instance. | |
| figmaFrameUrl | Yes | Figma frame URL to fetch design tokens from (e.g. https://www.figma.com/file/ABC123/Name?node-id=42%3A0). Must include the node-id query parameter pointing to the specific frame. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It details the audit process, 13 mismatch types, selector fallback strategy, prerequisites (FIGMA_API_TOKEN, Chrome on debug port), and return structure. Minor omission: no mention of side effects or idempotency, but it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense paragraph packing all information into a single block. It front-loads the purpose but enumeration of 13 types could be structured (e.g., bullet list) for readability. Every sentence adds value, but structure could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the input schema, return values (findings, summary with counts), and non-obvious dependencies. It lacks error conditions or examples, but the complexity is high and the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions in the schema. The description adds minimal extra meaning beyond stating that the URL must be reachable and the Figma URL must include node-id. Baseline 3 is appropriate since the schema already describes parameters sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Full design-to-implementation fidelity audit against a Figma frame.' It enumerates 13 specific mismatch types, selector fallback, and dependencies, making it distinct from sibling tools like argus_audit or argus_audit_full.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use cases for detailed audit but does not explicitly differentiate from siblings or provide when-to-use versus when-not-to-use guidance. It mentions required environment setup, which is helpful but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures everything currently broken on the open Chrome tab and formats it as a diagnostic context for Claude to read and suggest fixes. Does NOT navigate — reads the live tab state after user interactions, in authenticated sessions, or mid-flow. Returns { snapshot_id, summary, url, timestamp, critical_issues, warnings, js_errors, network_failures, console_errors, recent_requests, open_tabs }. Fix loop: pass the snapshot_id from a previous call as snapshot_id to get a diff — the response will include resolved (cleared since last snapshot), new_issues (appeared since last snapshot), and persisting (unchanged). Multi-tab: pass tabId to inspect a specific tab, or omit to read the active tab. The open_tabs array always lists all currently open Chrome tabs. Workflow: call argus_get_context → Claude suggests fix → apply fix → call argus_get_context with snapshot_id → verify resolved array is non-empty. Requires Chrome on --remote-debugging-port=9222.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional base URL to attribute findings to (default: TARGET_DEV_URL env var). Does not navigate — inspects the currently open Chrome tab. | |
| tabId | No | Optional Chrome page/tab ID. When provided, switches focus to that specific tab before capturing context — useful for SPAs that spawn new windows (e.g. OAuth popups, checkout flows). Get tab IDs from the open_tabs array in a prior argus_get_context response. | |
| snapshot_id | No | Optional snapshot_id from a previous argus_get_context call. When provided, the response includes resolved/new_issues/persisting arrays showing what changed since that snapshot. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden. It discloses that the tool requires Chrome on port 9222, does not navigate, reads live state, and provides diff capabilities via snapshot_id. It also explains behavior in authenticated sessions and mid-flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that is effective but slightly long. Every sentence earns its place, but breaking it into smaller sections or bullet points could improve scannability. Still, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description lists all returned fields and explains the diff workflow. It covers prerequisites, multi-tab handling, and use in a fix loop. This is comprehensive for a moderately complex tool with three optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 100%, the description adds significant context beyond the schema: it explains that 'url' does not navigate, 'snapshot_id' enables diff comparisons, and 'tabId' switches focus. This enriches the agent's understanding drastically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Captures' and clearly identifies the resource: 'everything currently broken on the open Chrome tab' formatted as diagnostic context. It distinguishes from siblings like argus_audit by stating it reads live tab state and does not navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('read the live tab state') and provides a complete workflow: call → suggest fix → apply fix → verify with snapshot_id. It also specifies when to use tabId for multi-tab scenarios, effectively differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the most recent Argus JSON report from the reports/ directory. Report includes a findings array and severity summary (critical/warning/info counts). Returns { "error": "No reports found in reports/" } when no audits have been run yet. Use to retrieve prior results without re-running a scan, or to pipe findings into another analysis tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It fully discloses return format, error condition, and that it reads from a file system directory. No mention of auth or side effects, but for a read-only tool, it is sufficient and not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with verb and resource, zero superfluous information. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully explains the tool's behavior, return format, and error handling. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4. Description adds value by explaining the return value and error case, which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the most recent report, specifies its contents (findings array, severity summary), and covers the error case. Distinguishes from sibling audit tools by mentioning avoiding re-running scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: to retrieve prior results without re-running a scan or to pipe findings. Implicitly excludes use for new scans, differentiating from argus_audit and argus_audit_full.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a targeted Argus audit on the routes affected by a GitHub pull request. Fetches the PR diff, maps changed files to routes in your target config using path-slug heuristics (infrastructure changes trigger a full audit; targeted otherwise) — or, when ARGUS_SOURCE_DIR points at the checked-out app source, framework-aware import-graph mapping that narrows a changed component or stylesheet to only the routes whose pages import it (Next.js + monorepo-aware, conservative-fallback on any ambiguity) — and audits only those routes — faster than a full scan and focused on what the PR actually touched. The audit target is resolved per-PR: an explicit targetUrl, else the PR's deploy-preview URL (ARGUS_PREVIEW_URL or opt-in GitHub-Deployments auto-detection), else TARGET_DEV_URL. Routes are audited with bounded concurrency (ARGUS_CONCURRENCY) and each route audit is timeout-bounded (ARGUS_ROUTE_TIMEOUT_MS) so a hung audit blocks rather than silently passing. Returns { findings, affectedRoutes, changedFiles, perRoute, summary, blocked, blockOn, baseline, reporting }. Blocking is baseline-aware: it gates on the findings the PR introduces vs a stored per-branch baseline (reports/baselines/.json, restored via actions/cache), failing safe to absolute counts when no baseline is available. When GITHUB_TOKEN and a resolvable PR are present it also posts/updates an Argus PR comment (surfacing new/persisting/resolved counts) and a GitHub Check Run (the same reporting the CI Action produces) — best-effort, never alters the block decision. Use in CI to gate merges: check blocked:true or pipe findings to an AI verdict step. Requires Chrome on --remote-debugging-port=9222. GITHUB_TOKEN env var recommended for private repos.
| Name | Required | Description | Default |
|---|---|---|---|
| prUrl | Yes | Full GitHub PR URL (e.g. https://github.com/owner/repo/pull/42). Used to fetch the list of changed files via the GitHub REST API. | |
| blockOn | No | "critical" = block only when critical findings exist. "warning" = block on any warning or critical. "none" = never block. Defaults to ARGUS_BLOCK_ON env var, then "critical". | critical |
| targetUrl | No | Base URL to audit (e.g. https://staging.example.com). Overrides TARGET_DEV_URL env var. | |
| githubToken | No | GitHub Personal Access Token or workflow GITHUB_TOKEN. Optional for public repos. Falls back to GITHUB_TOKEN env var. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description thoroughly covers all behavioral aspects: PR diff fetching, route mapping strategies, concurrency, timeouts, baseline-aware blocking, and best-effort commenting, plus prerequisites like Chrome and env vars.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the core purpose and then detailing process, outputs, and usage without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (4 parameters, no output schema, no annotations), the description covers all necessary information for correct invocation, including output structure, env vars, and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant context for each parameter, such as how prUrl is used, default behavior for blockOn, fallback logic for targetUrl, and token requirements above schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a targeted Argus audit on routes affected by a GitHub pull request, distinguishing it from sibling tools like full audit or visual diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using in CI to gate merges and contrasts with a full scan, including fallback logic and when infrastructure changes trigger different behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screenshot baseline comparison for a URL — captures a PNG screenshot and compares it pixel-by-pixel against a stored baseline using pixelmatch. First call: saves baseline, returns visual_baseline_created (info). Subsequent calls: returns visual_regression (warning ≥0.1% / critical ≥5% pixels changed) + visual_diff_summary (always). Baseline stored in reports/baselines/screenshots/. Use in CI or fix loops to detect unintended visual regressions without a full audit. Pass updateBaseline: true to force-refresh the stored baseline (e.g. after intentional UI changes). Requires Chrome on --remote-debugging-port=9222.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to capture and compare (e.g. http://localhost:3000/dashboard). Must be reachable by the running Chrome instance. | |
| baselineDir | No | Optional override for the baseline storage directory. Defaults to reports/baselines/screenshots/. | |
| updateBaseline | No | When true, deletes the existing baseline PNG and saves a fresh one from the current screenshot. Use after intentional UI changes to reset the reference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description details behavioral traits: first call saves baseline, subsequent calls compare, returns different signals with thresholds (0.1% warning, 5% critical), baseline storage path, and Chrome prerequisite. It covers the main behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: starts with core action, then first/subsequent usage, then CI context, then parameter guidance, then prerequisite. Slightly long but every sentence adds value and is logically ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values (visual_baseline_created, visual_regression, visual_diff_summary). Covers prerequisites (Chrome on port 9222) and threshold details. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 3 params described in schema). The description adds practical context: explains updateBaseline use for intentional UI changes, url reachability requirement, and baselineDir override. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core purpose: screenshot baseline comparison via pixelmatch. It distinguishes from sibling tools like argus_audit or argus_compare by focusing on visual regression detection between screenshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for use: CI or fix loops, and explains first-call vs. subsequent-call behavior. Lacks an explicit 'when not to use' but contrasts with 'full audit' and gives clear lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snapshots the currently open Chrome tab without navigating — captures console errors, network failures (4xx/5xx), CORS blocks, and auth failures in one poll. Returns { findings: [{severity, type, message, url}], newConsole, newNetwork }. Use during active development to inspect what is happening on the current page without running a full audit. Pass tabId to inspect a specific tab (get IDs from argus_get_context or list_pages). Without tabId, reads the active tab. Requires Chrome on --remote-debugging-port=9222 with a page already open.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional base URL to attribute findings to (default: TARGET_DEV_URL env var). Does not navigate — reads the currently open Chrome tab. | |
| tabId | No | Optional Chrome page/tab ID (e.g. from a prior argus_get_context response). When provided, switches focus to that tab before snapshotting — useful for SPAs that spawn new windows or multi-tab flows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description fully discloses behavior: does not navigate, uses Chrome remote debugging on port 9222, requires an open page, returns a structured response. It also explains that passing tabId switches focus. This is transparent and complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but front-loads the core action, then lists return fields, usage guidance, and prerequisites. Every sentence adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes the return structure and key fields. It covers prerequisites (Chrome remote debugging, open page), optional parameters, and contrasts with full audit. It is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds value by explaining that url does not navigate and tabId is for switching tabs, including how to obtain tabId from argus_get_context. This contextual usage guidance goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Snapshots the currently open Chrome tab' and lists what it captures (console errors, network failures, etc.). It distinguishes itself from a full audit by saying 'without running a full audit', and references sibling tools like argus_get_context and list_pages for tab IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use during active development to inspect what is happening on the current page without running a full audit.' It also explains when to pass tabId and when not to. However, it does not explicitly state when to use alternative tools (e.g., argus_audit) instead, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v9.6.6argus_pr_validatev9.5.5argus_design_auditargus_visual_diffv9.5.0argus_audit3 fields changedInput schema / properties / cacheAdded value: +{
+ "default": false,
+ "description": "When true, returns the cached result for this URL if one exists (from a previous argus_audit call in this session) without re-crawling. Use in fix loops to cheaply re-read the last audit while iterating on a fix. Cache is per-session, max 20 entries, LRU eviction.",
+ "type": "boolean"
+}Input schema / properties / critical / descriptionPrevious value: -"Treat this route as critical — console errors become critical severity"New value: +"When true, console.error calls are escalated to critical severity. Set true for business-critical routes (login, checkout, dashboard) where any error is a blocker."Input schema / properties / url / descriptionPrevious value: -"Full URL to audit (e.g. http://localhost:3000/checkout)"New value: +"Full URL to audit, including protocol and path (e.g. http://localhost:3000/checkout). Must be reachable by the running Chrome instance."argus_audit_full2 fields changedInput schema / properties / critical / descriptionPrevious value: -"Mark this route as critical — console errors are escalated to critical severity"New value: +"When true, console.error calls are escalated to critical severity. Set true for business-critical routes (login, checkout, dashboard) where any error is a blocker."Input schema / properties / url / descriptionPrevious value: -"Full URL to audit (e.g. https://example.com/dashboard)"New value: +"Full URL to audit, including protocol and path (e.g. https://example.com/dashboard). Must be reachable by the running Chrome instance."argus_get_contextargus_watch_snapshotv0.1.0argus_auditargus_audit_fullargus_compareargus_last_reportEach tool has a clearly distinct purpose: fast audit, deep audit, environment comparison, design fidelity, live context capture, report retrieval, PR validation, visual diff, and snapshot monitoring. Despite some conceptual overlap between argus_audit and argus_audit_full, they are explicitly differentiated by depth and scope, and descriptions clarify when to use each.
All tools follow a consistent 'argus_<descriptive_name>' pattern using snake_case, with clear verb-noun or noun phrases (e.g., argus_audit, argus_visual_diff). The convention is uniform and predictable.
With 9 tools, the set is well-scoped for a QA audit server. Each tool addresses a specific aspect of web quality assurance (basic audit, deep audit, visual diff, design audit, PR validation, etc.), and none feel redundant or unnecessary.
The tool surface covers the full lifecycle of QA auditing: fast checks, deep analysis, visual and design fidelity, environment comparison, live debugging, PR-specific validation, and report management. There are no obvious gaps; even baseline management and caching are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI QA tester — real browsers scan sites for bugs, SEO, perf, and accessibility issues via chat.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
AI QA that runs your app in a browser on every pull request: projects, test targets, test cases.
Voice-powered bug reporting with 13 MCP tools. Record bugs by talking; let AI find and fix them.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ironclawdevs27/Argus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
