Agents & MCP
MCP tools reference (all 15)
The complete Actuant MCP tool list: 12 free tools (scan_app, audit_app, get_scan, get_audit, get_findings, get_fix_brief, list_apps, scan_history, explain_check, check_data_exposure, verify_site, get_account) and 3 plan-gated tools for the Launch and Scale plans.
Last updated 2026-08-05
Actuant exposes 15 tools. The 12 free tools work the moment you are connected; the 3 plan-gated tools are always visible but the server rejects them with a clear plan_required error if your plan is too low.
Tool names are a contract and are deliberately unchanged, so scan_app and get_scan still run the single-page audit even though the product now calls it an audit everywhere else.
Ungated tools
Available on every plan. Two of them cover the single-page audit; two cover the whole-site audit.
| Tool | Arguments | What it does |
|---|---|---|
| scan_app | { url } | Run the single-page launch-readiness audit. ~20s; returns score, per-check findings, advice, and a report link. |
| get_scan | { scanId } | Fetch any previous single-page audit's full report. |
| audit_app | { url } | Start a whole-site audit: opens and tests every reachable page in a real browser. Runs for minutes, so it returns an auditId immediately. |
| get_audit | { auditId } | Poll a site audit: status, a live browser-view link while it runs, per-page scores, and site-wide findings. |
| list_apps | { } | The account's audited apps with the latest score per app. |
| scan_history | { url?, limit? } | Past runs, newest first — how the score moved over time. |
| explain_check | { check, host? } | Deep-dive on any check key: what it verifies, why it matters, how to fix it. |
| check_data_exposure | { url } | Supabase only. Asks the app's own backend for a row using the public key the page already ships, and reports which tables answered. Returns eligible: false, and probes nothing, when the app isn't on Supabase. |
| get_account | { } | Plan, app usage vs limits, total runs, connected keys. |
The whole-site audit (audit_app / get_audit)
scan_app grades one URL. audit_app crawls the site: it drives a real browser over every reachable page, scores each one, and reports the site-wide problems a single page can't show — broken links, dead assets, mixed content, orphan pages, runtime JavaScript errors, and inner pages that are weaker than the homepage.
Because a real-browser crawl takes minutes, audit_app returns an auditId and a reportUrl straight away and the crawl continues on a durable worker. Call get_audit with that id to poll. While the run is live, get_audit also returns a browserViewer URL — a full-screen view of the browser doing the crawl, worth handing to the person you're working for.
audit_app is metered
A whole-site audit is metered: it draws on your plan's weekly usage limit and then on usage credits. If the limit is exhausted, audit_app returns a message telling you to top up in Settings → Usage rather than starting a run. The single-page audit isn't metered this way.
The data-exposure check (check_data_exposure), and what "not eligible" means
A Supabase front-end hands every visitor two public things: the project URL and the anon key. That is by design — the boundary protecting your data is row-level security on the tables, not the secrecy of that key. So the question "can a stranger read my tables" is answerable from the outside, and check_data_exposure answers it the way a visitor's browser would: it loads the page, reads the app's own scripts to find the project and its public key, then asks the REST endpoint for a single row.
Eligibility is decided from the URL before anything is probed. If no Supabase project is found in the pages or scripts, the tool returns eligible: false with the reason no_supabase_detected and makes no request at all.
Seeing "not eligible"? Nothing is wrong
"Not eligible" is not a failure, not a warning, and not a passing grade. It means this particular check does not apply to your app — almost always because you are not on Supabase. It has no effect on your score: an ineligible check is excluded from the score entirely rather than counted as a zero, so an app on Firebase, Postgres, Rails or no backend at all is never penalised for it. There is nothing to fix and nothing to worry about.
The check is Supabase-only on purpose. Other backends fail the same way through different endpoints, and guessing at them would produce the kind of "probably fine" answer this product exists to refuse. If the site could not be loaded at all the reason is site_unreachable, which is kept separate — an unreachable site has not been shown to be safe.
When a project is found, the result is one of four:
| Result | What it means |
|---|---|
| rows_returned | An unauthenticated request came back with rows, and the tool names the tables. Worth acting on — but see the caution below. |
| no_rows_returned | Nothing came back without a login, which is consistent with row-level security being on. An empty table looks identical from outside, so this is not proof of a policy. |
| reads_refused | The backend refused unauthenticated reads outright. |
| undetermined | A project was found but the check could not finish. Undetermined is never reported as a pass. |
Rows coming back is evidence, not a verdict
rows_returned does not by itself mean row-level security is off. A table with a deliberate public read policy — a price list, published posts, a status page — looks exactly the same from outside. Actuant reports which tables answered and leaves the judgement to whoever knows the schema. Check the named tables against what you meant to be public before changing anything.
The probe is read-only and deliberately small: GET only, limit 1, at most five tables, and the table list comes from the project's own OpenAPI document rather than guesswork. Table names and yes/no answers are kept; row contents never are. It runs against the same app limits as a scan, so it cannot be pointed at arbitrary hosts.
Plan-gated tools
| Tool | Plan | What it does |
|---|---|---|
| fix_app | Launch | Open a GitHub pull request that fixes a run's failing checks with additive files (llms.txt, robots.txt, sitemap.xml). Needs GitHub connected and the app mapped to a repo. |
| submit_directories | Launch | The curated 20-directory launch checklist for an audited app: submit links, why each matters, prefilled copy, and what's already submitted. Assisted — you send the submission. |
| monitor_ai_visibility | Scale | Track when AI answers (ChatGPT, Claude, Perplexity) start citing your app. |
Valid check keys for explain_check — all 52 of them, generated from the audit engine: reachability, https-redirect, compression, http-version, redirect-chain, caching, hsts, csp, x-content-type, frame-guard, referrer-policy, permissions-policy, no-version-leak, security-txt, analytics, title-meta, canonical, meta-robots, title-length, desc-length, search-indexing, single-h1, heading-order, image-alt, internal-links, lang-attr, ai-visibility, ai-crawlers-allowed, ssr-content, semantic-landmarks, jsonld-present, org-schema, social-preview, og-complete, twitter-card, favicon, apple-touch-icon, manifest, doc-size, third-party, render-blocking, lazy-images, image-dimensions, mobile, theme-color, privacy-linked, terms-linked, footer-identity, contact-method, social-presence, payments, primary-cta.
If a tool returns plan_required, don't retry — the error names the plan and price to unlock it. The free plan covers one distinct app with unlimited re-runs.
Keep reading
Connect an agent
Step-by-step: add the Actuant MCP server to Claude Code, Cursor, VS Code, or Codex CLI, complete the OAuth sign-in, and verify all 15 tools are available.
API keys
For headless environments and CI where a browser can't open for OAuth, mint a manual bearer API key in Settings and pass it as an Authorization header to the Actuant MCP server.
Audit overview
Actuant scores any app URL 0–100 across 52 deterministic launch-readiness checks — delivery, security headers, analytics, SEO, AI-search visibility, structured data, social, performance, mobile, trust, and conversion. Here's every check and how it's weighted.