Let your coding agent run the scan

Your app was built by an agent, and the agent is right there. With xlogs as an MCP server it can scan your deployment, read back what was found and what was checked, and apply the fixes, without you copying anything between windows. Free, no key, and the scan runs on your machine: nothing is sent to xlogs.

Claude Code

claude mcp add xlogs -- npx -y github:damnepic/xlogs-cli#v0.2.4 mcp

Cursor, Windsurf and other MCP clients

Add the same command to the client's MCP configuration (in Cursor, .cursor/mcp.json in your project):

{
  "mcpServers": {
    "xlogs": {
      "command": "npx",
      "args": ["-y", "github:damnepic/xlogs-cli#v0.2.4", "mcp"]
    }
  }
}

Needs Node 18.18 or newer and git: npx fetches the tagged release (v0.2.4) from the public xlogs-cli repository, where you can read every line it runs.

The tools

Tool	Parameters	What it does
`xlogs_scan`	url, stack_only (optional)	Scan a deployed web app read-only for exposed secrets, publicly readable database tables, source maps, private files, missing security headers and DNS problems. Returns findings with evidence. Every request is a GET from this machine. Besides what a visitor fetches (the page, its scripts and source maps, a few of its own pages), a full scan requests files that must never be public (such as /.env and /.git/config) and /package-lock.json, and reads one row of each database table it finds as an anonymous user. It never writes, never sends credentials, and never exploits a finding. Run the full scan on your own deployment; for a site you do not own, pass stack_only: true. Free, no key.
`xlogs_receipt`	url, stack_only (optional)	What a scan CHECKED, not what it found: every check with its status (clear, found, not applicable, or could-not-complete) and the reason. Use this to tell 'nothing was found' apart from 'nothing was looked at'. Reuses the scan xlogs_scan just ran for the same URL instead of scanning again. Also lists what xlogs never checks on any site.
`xlogs_fix`	url, agent (optional), stack_only (optional)	Return one paste-ready document containing every finding's fix, ordered by severity, with what was observed and how to verify each change. Written for a coding agent to act on directly. Reuses the scan xlogs_scan just ran for the same URL instead of scanning again.
`xlogs_supabase_audit_sql`	none	Return read-only SQL the USER runs in their own Supabase editor to answer what an outside scan cannot: which tables have row level security off, what every policy's predicate actually is, which storage buckets are public, and what anon has been granted directly. Reads system catalogues only and selects from no application table. Sends no request at all; xlogs never connects and never receives the output.

The receipt is a tool of its own on purpose. Findings alone cannot tell an agent whether thirty checks ran or three; the receipt lists every check with its status, so the agent can tell "nothing was found" from "nothing was looked at". The receipt and fix tools reuse the scan the agent just ran instead of scanning the site again.

Try asking

"Scan https://my-app.vercel.app with xlogs and fix anything critical."
"Use xlogs_receipt: which checks could not run on my app, and why?"
"Give me the xlogs Supabase audit SQL so I can see which tables have row level security off."

What it sends

Every request is a GET from your machine. Unless it is stack-only, the scan also requests files that must never be public, such as /.env, and reads one row of each database table it finds; the complete list is on the methodology page. Run the default scan only on your own deployment. For a site you do not own, the agent passes stack_only: true, which reads only what a browser loading the page already fetches. To gate deploys on the same scan, see the CI gate.