Tools

Every tool the MCP server exposes, the permission it needs, and whether it writes

The server exposes 26 tools across seven areas. Your client always shows the live list after it connects — if this page and your client ever disagree, believe your client.

Three columns matter:

Scope — the permission the tool needs. A call without it fails with an error naming the missing permission; retrying will not help, you have to reconnect and grant it.
Writes — whether the tool changes anything.
Confirm — whether the tool is marked as needing confirmation. Most clients ask you to approve these before calling. It is set for anything that spends quota, changes customer-visible security state, or produces an artifact that outlives the conversation.

Organizations

Tool	Scope	Writes	Confirm	What it does
`list_organizations`	`mcp:read`	—	—	The organizations this credential can act in, and the identifier to pass as `organization`
`get_organization_usage`	`mcp:read`	—	—	Plan tier, usage against every limit, and whether the organization is approved for scanning
`create_organization`	`mcp:organizations:write`	yes	yes	Creates an organization owned by the calling account and returns the URL a human opens to pay

create_organization never charges anything and never collects payment details. It hands back a link; a person completes checkout in the browser. An organization-scoped API key cannot call it at all — see Agents as customers.

Applications

Tool	Scope	Writes	Confirm	What it does
`list_applications`	`mcp:read`	—	—	Applications with vulnerability counts by severity and scan schedule
`get_application`	`mcp:read`	—	—	One application plus its configured web and REST API scan targets
`register_application`	`mcp:applications:write`	yes	—	Registers an application and its target, and starts DNS domain verification. Uses an application slot from your plan
`verify_application_domain`	`mcp:applications:write`	yes	—	Runs the DNS TXT lookup and reports whether every target domain is proven yet
`get_domain_verification_status`	`mcp:read`	—	—	Domain-verification state for one application or the whole organization

verify_application_domain is not read-only even though it looks like a lookup: it performs an external DNS query, spends a bounded attempt budget, and can flip a domain to verified. It also issues a TXT record for a target domain that has no verification started yet, which is how a surface added after registration gets one. get_domain_verification_status answers the same question without spending an attempt.

An application registered over MCP cannot be scanned until it proves domain ownership. Every application enrolled through the MCP server or the REST API requires a DNS TXT record for each of its target domains, and every way of starting a scan refuses until all of them are verified. Applications you created in the dashboard are not affected — they are authorized by operator approval instead, and the tools will tell you which case you are in rather than claiming a block that will not happen. See Agents as customers.

Attack surface

Tool	Scope	Writes	Confirm	What it does
`get_asset_graph`	`mcp:read`	—	—	The discovered attack surface: asset nodes, their relationships, per-node open-vulnerability counts and test coverage
`expand_asset_cluster`	`mcp:read`	—	—	Lists the individual nodes folded into one cluster card returned by `get_asset_graph`

get_asset_graph returns a partial view by design — low-interest nodes are folded into clusters and large graphs are truncated, and the result says so. An assistant should check that before concluding something is absent from your attack surface, and use expand_asset_cluster rather than assuming a cluster is uninteresting.

Pentests

Tool	Scope	Writes	Confirm	What it does
`list_pentests`	`mcp:read`	—	—	Scans newest first, with status, timing, severity counts and cost
`get_pentest`	`mcp:read`	—	—	One scan in full, including failure details when it did not finish cleanly
`get_pentest_progress`	`mcp:read`	—	—	Live phase, per-agent execution counts and cost so far. Poll this, not `list_pentests`
`start_pentest`	`mcp:pentests:write`	yes	yes	Starts a real scan against your live systems and consumes monthly quota
`cancel_pentest`	`mcp:pentests:write`	yes	yes	Marks a running scan cancelled. See the warning below — it is not a kill switch

Cancelling a scan does not stop it costing you. It marks the scan cancelled, which discards whatever it had found — nothing is consolidated into vulnerabilities, triaged, or written into a report. But work already running keeps running to completion, so charges continue to accrue for some minutes after the call returns, and the scan still counts against your monthly quota. It cannot be undone. A scan that has not started yet cannot be cancelled; wait for it to be running.

start_pentest sends genuine attack traffic — authentication attempts, injection payloads, active probing — at the surfaces you registered, and spends a scan from your quota. It is deliberately marked as requiring confirmation. An assistant should never call it to "check" something it could have answered from existing results.

Vulnerabilities

Tool	Scope	Writes	Confirm	What it does
`list_vulnerabilities`	`mcp:read`	—	—	Summary rows, filterable by application, severity and status
`get_vulnerability`	`mcp:read`	—	—	One finding in full: impact, technical context, remediation guidance
`get_vulnerability_activity`	`mcp:read`	—	—	Merged timeline of status, assignment, due-date and note changes
`transition_vulnerability`	`mcp:vulnerabilities:write`	yes	yes	Moves a finding through its lifecycle

Exploit detail

get_vulnerability accepts includeExploitDetail, which defaults to false. While it is false, everything weaponisable is withheld: proof-of-concept and exploit code, test payloads, attack scenarios, patch-verification code, the resources a finding touched, and raw HTTP request/response logs — and the response lists which of them were withheld, so the assistant knows they exist and can ask you before requesting them. The call is recorded in your audit log either way.

The default is false because the common question ("summarise my open criticals") has no need of exploit code, and an unattended agent should not pull a working exploit into a transcript by accident.

Status transitions

transition_vulnerability enforces the same lifecycle the dashboard does:

open           → in_remediation | accepted_risk | false_positive
in_remediation → remediated | open | accepted_risk | false_positive
remediated     → fixed | open
any            → open

Moving to accepted_risk or false_positive requires a reason, which is recorded on the finding for the humans who will later rely on it. Moving to remediated schedules an automatic remediation-verification run against your target — which is why the tool asks for confirmation despite deleting nothing.

Reports

Tool	Scope	Writes	Confirm	What it does
`list_reports`	`mcp:read`	—	—	Published and failed reports. A report still generating is deliberately not listed
`get_report`	`mcp:read`	—	—	One report with severity totals, risk score and the written summary
`generate_report`	`mcp:reports:write`	yes	yes	Requests the report for a completed pentest. Asynchronous; publishing emails you
`export_report`	`mcp:reports:write`	yes	yes	Renders and returns a PDF download URL

export_report puts a PDF of your findings behind a permanent, unauthenticated link: it does not expire and cannot be revoked. Anyone who receives it can read the whole report. The same is true of an attestation's PDF link, including a private one.

Attestations

Tool	Scope	Writes	Confirm	What it does
`list_attestations`	`mcp:read`	—	—	Letters with visibility, redaction profile, expiry and view counts. Share ids are excluded
`get_attestation`	`mcp:read`	—	—	One letter, including its share link and content hash
`generate_attestation`	`mcp:attestations:write`	yes	yes	Creates a signed Letter of Attestation for a completed pentest

generate_attestation takes a redactionProfile (minimal, standard, detailed) and a visibility (private, unlisted, public). Visibility defaults to private. It requires a paid plan and spends one of the organization's attestations for the month; a call that exceeds either comes back as a plan-limit error.

Under the minimal profile the published severity counts are emitted as zeros by construction. They mean "suppressed", not "no findings" — do not read a minimal letter as a clean bill of health.

unlisted and public are both world-readable to anyone holding the share link, as soon as the PDF renders — there is no separate publish step. Only choose them when you actually want a shareable letter. Endpoints, payloads and evidence are never published at any redaction profile.

The `organization` argument

Every tool accepts an optional organization — a slug or organization id that chooses which of your organizations the call acts in. You only need it if you belong to more than one; if you do and you omit it, the call fails with an error naming them rather than guessing.

It selects among the organizations you already belong to. It cannot grant access to one you do not, and an organization-scoped API key rejects it outright if it names a different organization.

What tools never return

Credentials of any kind. Test-user passwords, API keys, bearer tokens, OAuth client secrets, deployment-protection bypass secrets, saved browser sessions and TOTP seeds are unavailable at every permission level.
Session material captured during a scan — by default, not unconditionally. Raw request and response logs from a finding can contain Authorization headers, cookies and session tokens our agents captured from your live system. They are withheld unless a call passes includeExploitDetail: true. They are gated, not scrubbed: redaction removes known fields, and it cannot reliably find a token embedded in the body of a raw HTTP log. Treat exploit detail as sensitive whenever you ask for it.
Anything outside your organization. Every call is re-authorized against your actual role, by the same permission checks the dashboard uses.

Untrusted text

Vulnerability titles, descriptions, application names and endpoint paths are partly derived from content our agents read on your target, which means an attacker who can influence a page can influence that text. Tools wrap it in an <untrusted> marker and the server tells your assistant, on connect, to treat those spans as data and never as instructions.

This makes injection visible rather than impossible. If an assistant ever reports that a finding "instructed" it to do something, that is the mechanism working — do not act on it.

Last updated: September 2, 2026

On this page