Sonar MCP tool reference

This reference groups registered tools by the Sonar capability they expose. The active profile may show only a subset; profile filtering and backend policy both apply.

First-use sequence

When the program ID is unknown:

list_programs { search }
        │ choose programId
        ▼
get_target_overview { programId }
        │ inspect scopes and counts
        ▼
list_domains / list_ports / list_http_paths / ...

If a trusted caller already has the program ID, begin at get_target_overview. Do not begin with an unbounded asset crawl or a scan launch.

Inventory reads

Tool	Purpose
`list_programs`	Discover programs by search and filters. This is the discovery entry point.
`get_program`	Fetch one known program.
`get_target_overview`	Fetch program, scopes, and per-asset-type counts before drilling in.
`list_scopes`	Page through a program's scopes.
`list_domains`	Page through domains.
`list_ip_addresses`	Page through IP addresses.
`list_ports`	Page through ports for a target or IP.
`list_http_paths`	Page through HTTP paths, status, length, and discovery source.
`list_technologies`	Page through detected technologies.
`get_http_path_technologies`	Fetch technology bindings for one HTTP path.
`get_port_technologies`	Fetch technology bindings for one port.
`list_mobiles`	Page through mobile application assets.
`list_wildcards`	Page through wildcard scope assets.
`list_cidrs`	Page through CIDR scope assets.

Paged list tools support their declared target and pagination filters. Use counts from the overview to choose what to read; do not request every asset type reflexively.

Workflow and scan reads

Tool	Purpose
`list_workflows`	Find current workflow versions; filter by category when selecting recon.
`get_workflow`	Inspect one workflow's category, parameters, graph, routing, and outputs.
`export_workflow`	Read its complete authoring document.
`list_scans`	List scans available to the service identity.
`get_scan`	Read one scan's status and progress.
`get_scan_tasks_statistics`	Read per-step task counts and recent errors.
`list_scan_results`	Page a compatible manifest-backed scan's frozen result revision.

Simple scans launched by the public create_scan flow refresh Inventory; read their useful effects through the Inventory tools after completion. list_scan_results is not a substitute for that refreshed-Inventory path.

Recon execution

create_scan starts one workflow version. Its strict arguments are:

Argument	Required	Meaning
`workflowDefinitionId`	Yes	Current workflow version ID from `list_workflows` or `get_workflow`.
`parameters`	No	Declared workflow parameter values. Omitted values use workflow defaults.
`trackResults`	No	Record task-to-asset provenance; defaults on for parameter-targeted scans.
`delaySeconds`	No	Non-negative pacing delay before task dispatch.

There is no per-scan secret argument. Steps receive current operator-managed global secrets at dispatch.

For the public pentest profile, select category AI, pass parameters: { program: "<program UUID>" }, and call exactly once. The simple create boundary is not idempotent; if the client loses the response, do not automatically retry.

Structural authoring

validate_workflow validates one complete workflow document against structural, graph, query, routing, timeout, and policy rules. It does not persist or execute the document. It is the only author-tier tool on the astrix-author MCP surface.

Asset synchronization

Tool	Purpose
`get_asset_schemas`	Fetch live accepted fields and examples for writable asset tables.
`upsert_assets`	Idempotently ingest approved discovered assets into Inventory.

These tools are exposed by sync and admin, not pentest. Programs and scopes cannot be created through external asset synchronization. Follow Inventory acquisition rules for parent-before-child writes.

Administrative inspection

The following read-tier tools are registered but excluded from non-admin explicit allow-lists:

list_workers and list_github_accounts;
get_ai_resolve_status and list_ai_resolve_runs;
list_needs_review_items; and
get_program_resolution.

They are operational or resolution-management views, not general target reads.

Administrative actions

The admin profile additionally exposes:

scan control: stop_scan, delete_scan;
workflow control: delete_workflow;
worker provisioning: create_worker;
resolution control: trigger_ai_resolve, approve_resolve_item, decline_resolve_item; and
scope-change inspection: list_scope_changes.

These actions remain subject to Sonar API authorization and validation. A tool being present does not bypass backend policy.

On this page