Audit a CLI tool or a website

Audit a CLI tool

anc is the reference linter for this standard. It scores any CLI tool against the eight principles and tells you, by audit ID, where it passes and where it falls short. The live audit above installs a tool in a sandbox and runs its binary and behavioral audits; for source and project depth, run anc locally.

Install

See /install for brew, cargo, and platform-archive instructions. Once anc is on $PATH, the rest of this page is what to do with it.

Run it

# Against the current project (cargo workspace, binary, or source tree)
anc audit .

# Against a compiled binary directly
anc audit ./target/release/mycli

# Agent-friendly output
anc audit . --output json

# Narrow to one principle
anc audit . --principle 3

Read the output

P1 — Non-Interactive by Default
  [PASS] Non-interactive by default (p1-non-interactive)
  [PASS] Has --no-interactive flag (p1-flag-existence)

P3 — Progressive Help
  [PASS] Help flag produces useful output (p3-help)
  [PASS] Version flag produces version output (p3-version)

P4 — Fail Fast with Actionable Errors
  [PASS] Rejects invalid arguments (p4-bad-args)

P6 — Composable Command Structure
  [PASS] Handles SIGPIPE cleanly (p6-sigpipe)
  [PASS] Respects NO_COLOR (p6-no-color-behavioral)

P7 — Bounded, High-Signal Responses
  [PASS] Has --quiet flag (p7-quiet)

Each line ends with a stable audit ID (p1-non-interactive, p2-json-output, p6-sigpipe, etc.). Cite those IDs in issues, commits, and agent output; they do not change between versions.

Three audit layers

• Behavioral: runs your compiled binary and inspects --help, --version, --output json, SIGPIPE, NO_COLOR, and exit codes. Language-agnostic.
• Source: ast-grep pattern matching on source code. Catches .unwrap(), missing error types, naked println!. Rust and Python today; more languages as they land.
• Project: file and manifest inspection. Looks for AGENTS.md, recommended dependencies, dedicated error and output modules.

Pass --binary for behavioral-only (skip source). Pass --source for source-only (skip behavioral). Most projects want the default, which is "run everything."

What a score means

A [PASS] is a requirement met, not a compliment. A [WARN] is a SHOULD the tool doesn't satisfy; ignoring it is a choice, not a bug. A [FAIL] is a MUST the tool doesn't satisfy; agents will hit the edge it describes, and the tool will surprise them. Nothing here is a vanity metric because the audits map one-to-one to the requirements on the principles page.

From an agent: CLI tools

An MCP client can score a CLI without the form. The anc.dev MCP server exposes score_cli, which installs and audits a tool live under its own per-source rate limits, and get_scorecard, which reads a curated or cached scorecard. Both take a tool name, an install command, or a GitHub URL, and score_cli returns the scorecard's URL.

See how widely-used CLIs score

The ANC 100 leaderboard is what running anc audit produces at scale: every popular CLI tool, scored against the same eight principles, with full per-audit evidence under /score/<name>. The scoring rules are documented on the methodology page; the underlying JSON schema is enumerated at /scorecard-schema.

Source: github.com/brettdavies/agentnative-cli.

Audit a website

The website audit probes the agent-facing surface of any public site: its MCP server, its MCP and agent discovery surfaces, its machine-readable content (llms.txt, OpenAPI, JSON Schemas), its root-HTML affordances, and its crawl policy. The result is a web scorecard with per-check evidence and copy-paste fixes, at a shareable /score/<host> page.

What a website audit checks

The audit runs entirely as network probes: HTTP requests, a JSON-RPC handshake over streamable-HTTP, a CORS preflight, and DNS-over-HTTPS lookups. There is no crawler and nothing is installed. Every check carries a MUST, SHOULD, or MAY keyword and belongs to one of six categories:

• Discoverability: robots.txt, sitemap.xml, Link headers, <link rel> pointers, DNS-AID records under _agents, and an agent-friendly 404: a nonsense path MUST return HTTP 404 or 410 (a soft-200 SPA shell is broken), and the markdown 404 twin SHOULD carry at least one recovery link (sitemap.xml, llms.txt, or docs).
• Content for agents: llms.txt (root and per-section), llms-full.txt, and markdown content negotiation: Accept: text/markdown, the markdown twin served to bare CLI and library User-Agents and to AI user-fetchers that state no content-type preference, Accept: text/plain treated as a markdown request, and Vary: Accept, User-Agent on the negotiated response. Root HTML MUST carry an H1 and enough visible text for a non-JS agent; a discoverable llms.txt twin can mark that floor not-applicable rather than crediting a JS shell. When llms.txt is present, three quality rows score format (H1, summary, link index), whether those links resolve, and a when-to-use or programmatic-access heading. Plus the other root-HTML affordances (meta description, <noscript>, JSON-LD, semantic landmarks).
• Bot and crawl policy: AI-crawler rules, Content-Signal directives, security.txt, Web Bot Auth, and agent-UA reachability (GET / with a user-fetcher User-Agent must not land on a challenge interstitial).
• API: an OpenAPI description, referenced JSON Schemas, a .well-known/api-catalog (RFC 9727), JSON client-error bodies (not HTML), and rate-limit headers on a safe GET.
• MCP: the initialize handshake, tools/list with input schemas, resources/list when capabilities.resources is advertised, the modern era (protocol revision 2026-07-28) scored as its own lane, per-era JSON-RPC error-code conformance, a prompt GET answer (no held-open hang), CORS preflight and actual, the .well-known server card, a usage doc, and WebMCP. Each protocol era scores independently: a dual-stack server earns both lanes, and a single-era server fails exactly the lane it lacks.
• Agent discovery and auth: the A2A agent card, optional /.well-known/ai-catalog.json (ARD), agent-skills index, OAuth discovery metadata, and auth.md.

A check is scored only when it applies: MCP checks need a discovered endpoint, API checks need an API surface, and a declared site type (content or api) scopes the rest. Anything that does not apply is n_a and never counts against the site. Two scores come out of one run: the site score (the headline) measures the site against the checks that apply to it, so a site perfect for its type approaches 100%; the global score measures it against a maximally agent-ready site, so exposing and nailing more surfaces ranks higher. A present-but-broken surface costs more than an absent one, because it misleads agents. A surface that works while violating a spec detail reads noncompliant and earns partial credit, so showing an imperfect capability always beats withdrawing it.

From an agent: websites

An MCP client can run the audit without the form. The anc.dev MCP server exposes four web tools:

• audit_website(url, site_type?, public_listing?): run a fresh audit; every observed non-passing row carries inline remediation with a copy-paste prompt.
• get_website_audit(url): read a cached scorecard without re-running.
• list_website_audits(view?): the web leaderboard, curated by default.
• get_web_remediation(check_id, evidence?): the canonical fix for any check, with a ready-to-paste prompt. Pass the failing row's evidence and it is appended to the prompt as a delimited, untrusted data block.

Every response carrying a scorecard also carries cached, scored_at, and refresh_after beside it. A cached entry younger than one minute is served as-is; past refresh_after a repeat request tries a fresh audit instead. That is cache-expiry eligibility, not a guarantee: the operator kill switch, the per-source rate limits, and probe failures can still refuse, and the cached scorecard is served as data when they do. Full contract at response freshness.

See how sites score

The web leaderboard ranks a curated set of sites by their agent-readiness, and each row links to its scorecard with full per-check evidence and fixes.