Security Scanning for AI Agents: How the OnScanner MCP Server Works

TL;DR: The Model Context Protocol (MCP) is an open standard that lets AI agents call external tools. The OnScanner MCP server exposes seven tools through which an agent can create scan targets, start live security and privacy scans, poll for completion, and read structured findings. It authenticates with the same API key as the REST API and only ever operates on targets your account is authorized to test.

AI agents are quickly becoming operators of development and security workflows: they read code, open pull requests, and increasingly run the tooling around them. Security scanning is a natural fit for that pattern, because a scan is a well-defined job with structured output that an agent can reason about. This post explains how OnScanner plugs into agents through its MCP server: what MCP is, what the seven tools do, what a typical flow looks like, and where the plain REST API remains the better choice.

What is MCP, and why give a scanner one?

The Model Context Protocol is an open standard for connecting AI assistants to external tools and data. An MCP server describes the tools it offers in a machine-readable form; a connected agent can then call those tools with structured arguments and receive structured results, without anyone writing bespoke integration code for each assistant.

For a scanner, that unlocks a genuinely useful workflow: you can ask an assistant in your editor or chat to "scan staging and tell me what is actually exploitable," and the agent handles the whole loop, from starting the scan to summarizing the findings. The division of labor is the important part. The agent orchestrates and interprets; the scanning itself remains OnScanner's deterministic engines doing exactly what they do when a human clicks the button.

What tools does the OnScanner MCP server expose?

Seven tools cover the full scan lifecycle: managing targets, running scans, and retrieving results.

The surface is deliberately small: everything an agent needs to run and read a scan, and nothing else.

What does a typical agent flow look like?

Given a prompt like "run a security scan on example.com and summarize what needs fixing," a connected agent works through four steps:

1. Resolve the target. The agent calls list_targets to find an existing entry for the domain, or create_target to add it if the account does not have it yet.
2. Start the scan. start_scan returns a scan id immediately; the scan itself runs asynchronously on OnScanner's side, live against the target.
3. Wait for completion. The agent polls get_scan_status with that id until the status reaches SCAN_COMPLETED.
4. Read and summarize. get_scan_results returns structured findings, which the agent distills: severity distribution, version-matched CVEs with EPSS and CISA KEV context, patch status, any confirmed-exploitable issues, and tracker or consent findings for privacy scans.

Because the results are structured data rather than a PDF, the agent can do more than summarize. It can compare a scan against the previous one, filter for KEV-listed findings, draft remediation tickets, or decide that a finding warrants waking someone up. If you are new to what a good scan-and-triage loop looks like in general, our guide How to Scan a Website for Vulnerabilities covers the process the agent is automating.

How do you connect an agent?

The server lives at https://mcp.onscanner.com/mcp and speaks Streamable HTTP. Authentication is an OnScanner API key sent in the ONSCANNER-KEY header; Authorization: Bearer <key> is also accepted. Keys are created in the app at app.onscanner.com under API Keys, and the same key works for both the MCP server and the REST API.

Connecting from Claude Code is a one-liner:

claude mcp add onscanner --transport http https://mcp.onscanner.com/mcp \
  --header "ONSCANNER-KEY: <your-api-key>"

Clients configured with JSON, such as Claude Desktop, Cursor, or VS Code, use the standard block:

{
  "mcpServers": {
    "onscanner": {
      "url": "https://mcp.onscanner.com/mcp",
      "headers": { "ONSCANNER-KEY": "<your-api-key>" }
    }
  }
}

Full connection instructions, including calling the server through the Anthropic API's MCP connector, are in the API docs.

Who is allowed to scan what?

The non-negotiable rule carries over unchanged from the rest of the platform: you may only scan targets you own or are explicitly authorized to test, and this is enforced at the account level. An agent holding your API key operates strictly within your account's target list; create_target is where authorization is asserted, and handing an assistant your key does not turn it into a tool for scanning the open internet.

It is also worth being precise about where AI sits in the picture. The scan itself never calls an LLM: the engines are deterministic, and the agent stands entirely outside the scan, issuing commands and reading structured output. AI Findings, OnScanner's own analysis layer, is a separate feature that is optional and opt-in per scan. And the safety properties hold regardless of who pressed the button: active exploitation checks remain non-destructive and in-band whether a scan was started by a human, a schedule, or an agent. The methodology documents both boundaries.

What if you would rather use plain HTTP?

Everything the MCP server does is also available over the REST API, with the same key. The base URL is https://api.onscanner.com, authenticated with the same ONSCANNER-KEY header, and the common endpoints mirror the tool list: GET /me/, GET /targets/, POST /targets/, POST /scan/, GET /scans/, and GET /scan/{id}/. Interactive documentation and the OpenAPI spec live alongside the MCP instructions in the API docs.

The REST API is the better choice wherever you do not want an agent in the loop: CI pipelines that scan on every deploy, cron jobs, dashboards, and anything that should behave identically every time. Many teams end up using both, REST for the deterministic automation and MCP for interactive investigation, and since both run the same live scans against the same account, the results are interchangeable.

How do agents discover OnScanner on their own?

Agent-facing infrastructure only works if agents can find it, so OnScanner publishes machine-readable discovery documents: an llms.txt index at onscanner.com summarizing the product and the MCP tools in plain markdown, an MCP server card at a well-known URL describing the endpoint, transport, tools, and authentication, and published agent skills with step-by-step instructions for security scans, privacy scans, and target management. An agent landing on the domain can work out how to connect without a human pasting documentation into its context.

Trying it costs nothing: the Starter tier is free, Professional is $60 per month, and the pricing overview has the details. The agent interface is not a separate product, just another door into the same live scanner.

Frequently asked questions

Does the OnScanner scan itself use AI?

No. The scan is fully deterministic and never calls an LLM; every finding comes from a specific engine and a specific observed signal. MCP changes who can operate the scanner, not how it works: the agent issues commands and reads results from outside. AI Findings, the optional analysis layer that summarizes and prioritizes results, is separate and strictly opt-in per scan.

Can an AI agent scan any website with these tools?

No. The MCP tools operate only on targets inside your OnScanner account, and you may only add targets you own or are explicitly authorized to test, a rule enforced at the account level and by the Terms of Service. An agent with your API key inherits exactly your account's authorization boundaries, nothing more, so it cannot be pointed at arbitrary third-party sites.

Do the REST API and the MCP server need separate keys?

No. One OnScanner API key, created at app.onscanner.com under API Keys, authenticates both: send it in the ONSCANNER-KEY header for REST calls and for the MCP server, where a Bearer token is also accepted. That makes it easy to run REST-driven scans in CI while an agent uses MCP interactively, all under the same account and the same authorization rules.