OpenSEO's three site-audit MCP tools—run_site_audit, get_audit_status, and get_audit_issues—coordinate around a single audit lifecycle: initiate a crawl with run_site_audit, poll its completion status, then retrieve findings sorted and filtered by severity and type. The tools default to the project's most recent audit and manage scale with configurable page budgets and issue result limits, ensuring agents can query partial results from failed audits and gracefully handle audits predating issue data collection.
The three site-audit MCP tools — run_site_audit, get_audit_status, and get_audit_issues — are implemented in site-audit-tools.ts; the auditId parameter is optional in all three, and when omitted each tool resolves against the project's most recent audit.[1]
The maxPages parameter of run_site_audit accepts integers between 10 and 10,000; the default page budget (as tracked in analytics) is 50.[1] When runLighthouse is false (the default), run_site_audit sets lighthouseStrategy to "none"; when true, it sets it to "auto".[1]
The run_site_audit handler calls AuditService.resolveAuditLimitTier to determine the billing tier, then calls AuditService.startAudit to begin the crawl.[1] On success, run_site_audit emits a "site_audit:start" PostHog event recording project_id, max_pages, run_lighthouse, and source: "mcp".[1] run_site_audit starts a crawl and returns immediately; agents must poll get_audit_status until the audit reaches a terminal state (completed or failed) before treating results as final.
The resolveAudit helper in site-audit-tools.ts fetches a specific audit by ID if auditId is provided, or falls back to AuditRepository.getLatestAuditForProject; it throws AppError("NOT_FOUND") if no audit is found.[1]
A failed audit with pagesCrawled > 0 still holds partial results; get_audit_status instructs agents to call get_audit_issues on a failed audit rather than treating it as having no data.[1]
The limit parameter of get_audit_issues defaults to 200 and is capped at 1,000.[1] The get_audit_issues handler passes severity and issueType filters into AuditRepository.getIssuesForAudit, then sorts and slices the result client-side.[1]
get_audit_issues sorts issues severity-first (using ISSUE_SEVERITY_ORDER) so that when the result is truncated by limit, info-severity rows are dropped first and critical rows are never lost.[1] The get_audit_issues response includes a summary array that groups issues by type with count and severity, sorted severity-first then by descending count.[1] When no issues match and no filters are applied, get_audit_issues hints that audits run before issue checks existed have no issue data and should be re-run with run_site_audit.[1]
Sources