Ask WASViking from your AI client (MCP): what agents can see and start
What an AI client connected to the MCP Gateway (Lovable, Claude Code, Cursor, VS Code) can read and start in WASViking - targets, repositories, findings with every filter and the evidence to fix them, the Infrastructure Defense fleet (hosts, updates, remediation, agents, coverage), the monitored certificates, scans on registered targets, new analyses of monitored repositories, and the comparison that tells whether a fix worked - with the protections that apply.
Two built-in MCP servers of the AI Guardian MCP Gateway give your AI client the WASViking data it needs while it works, and let it ask for a scan without leaving the chat:
- WASViking® security data is read only. It lists what WASViking knows (targets, repositories, assets, hosts, cloud resources), searches findings with every filter the Findings page offers, returns the complete record of a finding with the evidence a developer needs to fix it, follows scans and compares two scans of the same target or repository. It also answers what the Infrastructure Defense screens show (the fleet, what changed, updates, remediation, agents, coverage, gateways) and what the SSL Monitor knows about your certificates.
- WASViking security actions starts things, on what WASViking already knows: a web scan of a registered target and a new analysis of a monitored repository. Nothing is registered or connected from the chat.
Both work with every client that speaks MCP over Streamable HTTP. Plan for ten minutes to add the servers and tick their tools.
Before you start
- The MCP Gateway is on and your client is connected to a gateway (see Govern agent tools with the MCP Gateway).
- You have an administrator role, or a role with AI Gateway manage access.
- For scans of web targets: the target is registered in Targets and was scanned at least once from the portal, so it has a scan profile. For analyses of repositories: the repository is connected and monitored in Settings, Repositories.
Step 1: add the servers and tick the tools
Open AI Guardian, Protection, MCP Gateway, then Servers, and select Add WASViking security data (read-only) and, if your agents may start scans, Add WASViking security actions (starts scans). Both are WASViking verified entries of the App Catalog as well.
What you should see: the tools arrive approved (first-party servers scan clean). On the Gateways tab, tick the ones your client may use; the read tools carry the class read, the two action tools carry the class write. A gateway created with the secure default rules lets a write on a known target through and asks a person's approval on an unknown or high-risk one; a policy rule on the gateway can require approval for every scan start.
What the client can ask
The names below are the tool names your client sees, prefixed by the server
identifier (wasviking__ and wasviking_actions__).
| Need | Tool | What it answers |
|---|---|---|
| See the web targets | list_targets |
Name, URL, scan profile, scan in progress or last completed one, schedule, open findings by severity, whether a scan can start now |
| See the repositories | list_repositories |
Provider, branch, monitored or not, last analysis, run in progress, open findings, whether a new analysis can be asked now |
| See everything WASViking knows | list_assets |
Targets, domains, hosts, repositories and cloud resources by name, with environment and exposure |
| Start a scan on a registered target | start_web_scan |
The scan started, or the one already covering the target |
| Analyse a monitored repository again | rescan_repository |
The run queued, or the one already in progress |
| Follow a scan | get_scan_status |
By target, by repository or by the id a start answered with |
| Find findings | list_findings |
Filters: modules, severities, statuses, categories, repository, target, URL prefix, CWE, OWASP, SLA, dates, the scan that saw them, words in the title; sorting and paging; detail=full returns every field |
| Read one finding in full | get_finding |
Title, summary, severity, risk score and its factors, lifecycle (new, open, in progress, reopened, resolved, accepted risk, false positive) with who changed it and when, SLA, owner, where it is, how to fix it, references, CWE and OWASP, the scan that saw it last, a portal link and the scrubbed evidence |
| Know whether a fix worked | compare_scans |
Findings open before the last scan against the open ones now, what it resolved, what appeared, what came back |
| Check a library | check_component |
Where the library is used, the open advisories on it and the advisories known for the package |
| Host vulnerabilities and posture | list_host_vulnerabilities, get_host_posture |
CVEs with package, fixed version, CVSS, EPSS and KEV; the complete host (see the Infrastructure Defense table below) |
| Cloud findings and attack paths | list_cloud_findings, get_attack_paths |
Posture findings with resource, control and fix; active attack paths with the options to break them |
| Leak exposure | get_exposure_summary |
Leak matches of the monitored domains in 90 days: counts and dates only |
| Executive view | get_executive_summary, get_security_posture, list_top_findings |
Counts by module and severity, the last 30 days, SLA, the worst open items |
| What ran and how it went, in a period | get_scan_activity |
Web and API scans, Code Security runs, SBOM and secrets submissions and mobile assessments in a period (last 30 days, last_month, 2026-10, a quarter, a range): totals and success rate by module and by source (portal, schedule, CI/CD pipeline, API, AI client, auto-discovery, AI Scan Planner, push event, Sentinel agent), the failures with their reason, the CI/CD runs with provider, repository and branch and their failures, what is running now, the targets and monitored repositories that did not run, against the previous period |
| Every run of a period | list_scan_runs |
Most recent first, with status, source, start, end, duration, the reason of a failure or a skip, the pipeline provenance and the results (findings by severity, counts of a repository run, components and vulnerabilities of an SBOM, matches of a secrets scan, grade of a mobile assessment); filters by module, status, source, failed only and asset name; paged |
Example requests, in the client's chat:
List my web targets and start a scan on https://app.example.com.
Show every high and medium finding of the repository acme/payments-api with the full detail, so you can fix them.
I pushed the fix. Analyse acme/payments-api again and, when it finishes, tell me what changed.
What ran last month across DAST, SAST, SBOM and secrets, what failed and why, and did our CI/CD pipelines have problems?
Infrastructure Defense and certificates
The same read-only server answers what the Command Center, Resolve, the Agents screen and the SSL Monitor show, so an agent can analyse the fleet without opening the portal. Nothing here changes a host: patches, reboots, approvals, risk acceptances and policies stay in the portal.
| Need | Tool | What it answers |
|---|---|---|
| See the fleet | list_hosts |
Every host with operating system and support status, environment, criticality, exposure, status, management state, risk score and the score expected after updates, vulnerability counts, missing patches, pending reboot, compliance, agent version, last contact, site and tags; filters on each and sorting |
| One host in full | get_host_posture |
The host above plus the score factors, the compliance detail, the pending update items, the updates on hold, last boot, sessions, resource use, hardware, cloud placement, volumes, running services and the state of the security settings |
| Host vulnerabilities as findings | list_findings with module: ["infrastructure"] |
Detections with package, fixed version, CVSS, EPSS and KEV, in the same shape as the other modules |
| What changed | get_fleet_changes |
New and fixed vulnerabilities in a period, hosts that joined, hosts silent now and remediation jobs finished; for the fleet or one host |
| The trend | get_fleet_trend |
The daily series of score, hosts, findings, criticals and highs, pending security updates and compliance, with the change over the period |
| Software | list_software, find_software |
The inventory consolidated across hosts with vulnerabilities and category; where one software is installed, with its open vulnerabilities |
| Pending updates | list_pending_updates |
Per host: missing patches, pending and security updates, reboot and the score expected after everything; for one host, the items themselves and the updates on hold |
| Remediation history | list_remediation_jobs |
Jobs with packages, status, the score before, expected and verified after, who asked and who approved, when they ran |
| Expected score after a selection | get_remediation_impact |
What a host's score would be after the chosen pending security updates, with the detections that close by severity; a preview, nothing is applied |
| Risk acceptances and deadlines | list_risk_acceptances |
Vulnerabilities accepted, ruled not applicable or mitigated, with who, why and until when; open vulnerabilities past their SLA deadline |
| Network exposures | list_network_exposures |
Open exposures by host, port, service, kind and severity, with the PCI reference |
| Configuration checks | list_config_findings |
Failing CIS-style checks grouped by check across the fleet, or per host with expected and actual values |
| Agent hygiene | get_fleet_hygiene |
Agents by status and version, silent agents, enrollments that never reported, tokens never used, duplicate names, activation keys |
| Unmanaged hosts and probes | list_unmanaged_assets |
Hosts seen without a managing agent, the probes, the networks they watch and the recent probe scans |
| Attack surface coverage | get_coverage |
How much of the internet-facing surface is served by a managed host, by state and reason, asset by asset |
| Gateways, sites, policies | list_gateways, list_sites, list_policies |
Gateway health, roles, traffic and alert settings; sites with their networks and gateways; what each policy assesses and how it patches |
| Certificates | list_certificates, get_certificate |
The monitored certificates most urgent first (expired, expiring, valid) with issuer, days remaining, obsolete TLS versions, monitoring and reachability; one name with its history, events and open SSL findings |
Example requests:
Which production hosts are missing critical patches, and what would their score be after the security updates?
Which certificates expire in the next 30 days or still accept TLS 1.0?
Edge Threat Radar
The same read-only server answers what the Threat Radar, the Edge Threat Details modal and the Enforcement screen show, so an analyst can ask the chat who is hitting the edge, from where, whether an address is a bot, a scanner or a person, what WASViking decided about it and why, what the edge already stopped and what reached the application, and who is blocked. Every answer that names an address opens with known infrastructure: the address is on your trusted list, the verdict reads it as your own systems, your team unblocked it as yours within 90 days, or it is a verified operator. An address marked as the company's own is never offered as a candidate for a block. Blocking and unblocking stay in the portal in this wave; the verdict is decided by WASViking and the chat only explains it.
| Need | Tool | What it answers |
|---|---|---|
| What needs you now | get_edge_overview |
Addresses by verdict, action and bucket, by classification and by coverage, the traffic totals, how many addresses are your known infrastructure, top countries, hostnames and actor kinds, the blocks in force, the automation mode and the collectors |
| Who is hitting the edge | list_edge_actors |
Every address of the window with known infrastructure, identity (kind, verification, hosting platform, operator, country, reverse DNS), the verdict with confidence, action, severity and blocking cost, classification, risk, traffic, hostnames, reputation, the block in force and the community card; filters on each, sorting by risk, confidence, requests, last seen, severity or hostile probability |
| One address in full | get_edge_actor |
The dossier: identity with user agents, every signal of the verdict, the kinds of path asked and the application's answers, the collectors that saw it, blocks in force and past, the newest raw requests and the briefing |
| Should I block this? | check_edge_block |
Known infrastructure first, the recommendation decided by WASViking, whether a block through the chat would be accepted and why not, whether the automatic gate would block it now with every check, the evidence for and against |
| Which addresses deserve a block | list_edge_block_candidates |
Hostile addresses ranked by the evidence, each with the evidence for and against and the official action of the verdict; trusted, own and already blocked addresses left out and counted |
| What one address did over time | get_edge_actor_activity |
Requests by day or hour, stopped at the edge, WAF events, hostnames, kinds of path and response statuses, with the activity after a block |
| The raw requests | search_edge_events |
The newest requests within retention by address, hostname, path fragment, kind of path or event type; query strings removed |
| The collectors | list_edge_targets |
Cloudflare zones and Cloud Armor policies with their state, last run, blocklist and trusted list, events and the plan limits |
| Who is blocked | list_edge_blocked, get_edge_enforcement_record |
The enforcement ledger with who decided, when, the provider, the verdict at the time and the activity after the block; one record with its timeline |
| Your own infrastructure | get_edge_allowlist |
The trusted addresses and ranges of your collectors and the addresses your team unblocked as yours or a partner's |
| The automation | get_edge_automation |
Decision assist and automatic blocking as set, the floors, and what the gate decided in the window, live or in shadow |
| The definitions | get_edge_method |
Verdicts, actions, confidence floor, severity and blocking cost scales, when a block is recommended, coverage states, actor kinds, known-infrastructure statuses, evidence categories, community statuses, the order of the gate and the unblock reasons |
For the CISO and the manager, the same module answers by period, in the
words of the executive tools (last_month, last_quarter, 2026-Q3,
2026-08, 2026, a range), from a daily aggregate that keeps no address:
| Need | Tool | What it answers |
|---|---|---|
| The volume of risk | get_edge_risk_summary |
Requests, stopped at the edge and reached the application, sensitive requests answered, address-days by verdict, action and coverage, hostile and block-recommended address-days, blocks and unblocks, the gate's outcomes, top countries and actor kinds, compared with the previous period |
| Is it getting worse | get_edge_trend |
The series by day, week or month and the change from the first to the last point |
| Where it comes from | get_edge_breakdown |
One dimension with counts and shares: verdict, action, classification, actor kind, coverage, known infrastructure, country, hostname, kind of path, rule type, response class, provider |
| What the perimeter let through | get_edge_exposure |
Sensitive requests and the ones the application answered 2xx, by kind and by hostname, with the hosts to check |
| Are the blocks precise | get_edge_enforcement_metrics |
Blocks by source, time from first sighting to block, addresses still active after the block, blocks released later and the precision, unblocks by reason, what the gate would have blocked |
| Does the radar see everything | get_edge_coverage |
Collectors, events kept against the plan's capacity, days with events, retention, aggregate rows present |
| Two periods side by side | compare_edge_periods |
The headline numbers of two periods and their difference |
To act, the security actions server offers two write tools that go through the Threat Radar's own flow, the same one the Block button and the Unblock button use (provider, ledger, audit trail, notification). Only a person signed in with a WASViking role that allows it can call them; a key is refused; an address on the trusted list, read as your own infrastructure or unblocked by your team as yours is refused with the orientation to use the portal; a new gateway's secure defaults ask a person to approve a block before it runs.
| Need | Tool | What it does |
|---|---|---|
| Block an address | block_edge_address |
Blocks it on the provider that saw it, with the reason given in the chat kept on the record; answers an existing block instead of repeating it |
| Remove a block | unblock_edge_address |
Removes a block WASViking applied, with one of the seven reasons; the four "not a threat" reasons stop the automatic gate for 90 days, and the two ownership reasons can add the address to your trusted infrastructure |
Example requests:
Among the addresses seen this week, which ones should I really block, and which of them are our own infrastructure?
Compared with last quarter, is the edge getting worse? Which countries and hostnames drive it, and did the application answer any sensitive request?
Is 203.0.113.9 a bot or a person, where does it come from, and why did WASViking not block it on its own?
Executive risk for leadership
The same server answers what the Executive Security Report tells managers, directors and CISOs, for any period and in a chat: the numbers of the PDF, computed by the same rules, aggregate only. A gateway created with the guided setup goal Discuss risk and the executive report with leadership has only these eleven tools on, so a director can use the AI without any asset-level detail reaching it; the same tools can be switched on in any gateway from the module Executive risk & reports.
| Need | Tool | What it answers |
|---|---|---|
| The period at a glance | get_risk_overview |
Found, fixed (confirmed by retest or closed by the team), false positives, accepted risk, open and past deadline at the end, typical time to fix, fixes within the deadline; the comparison with the previous period over the areas monitored in a comparable way, with the reason each other area is left out; the split by severity; accepted-risk decisions due; every area with its coverage; the quarters of the year; the rule-based next steps; signals: areas that improved or worsened most, the severity with the worst SLA, areas whose backlog is aging, the pace of new against fixed over 3 and 6 months |
| Quarter by quarter | get_quarterly_trend |
Up to 20 quarters, a year, a span or the last N, with the change between consecutive quarters; one area (with its coverage and whether consecutive quarters are comparable) or some severities; fiscal quarters when the fiscal year starts in another month |
| Month by month | get_monthly_trend |
Up to 36 months, the same columns |
| Two periods side by side | compare_periods |
Any pair (this quarter against the same quarter last year, two semesters), totals over the comparable areas, every area with its comparability, severities in both |
| By area | get_area_breakdown |
Each area with coverage in both periods, comparability and its reason, the types of issue with found, open, fixed and false positive, open issues per monitored asset, open by severity |
| By severity | get_severity_breakdown |
Found, fixed, open, overdue, typical time to fix and SLA per severity against the previous period, plus the age of what is open at the end of the period |
| Open backlog on a date | get_open_backlog |
Within the deadline against past it, critical and high, the age of the backlog, the types of issue that weigh most, the accepted-risk decisions in force, expiring or expired |
| SLA and time to fix | get_sla_performance |
Fixes within the deadline, typical, mean and 90th percentile time to fix, by severity (with its deadline) and by area, against the previous period |
| The PDFs leadership received | list_report_editions, get_report_edition |
The editions generated or emailed, with their cover numbers, and the full numbers one edition carried, by the code printed in its footer |
| How the numbers are computed | get_report_method |
Definitions, the coverage rule, detection changes, the reliability gates in force, the deadlines, the time zone and how a period may be named |
A period may be named as last_quarter, quarter_to_date, last_month,
month_to_date, year_to_date, a quarter such as 2026-Q3, a month such as
2026-08, a year such as 2026, or a range such as 2026-01-01..2026-06-30
(up to three years). Every number travels with the reason it is unavailable
or not comparable (coverage changed, monitoring started, detection widened,
fix counts held back until a new scan confirms them), so the AI explains the
change instead of reading more monitoring as more risk. Closed months anchor
"open at the end" on the same month-close records the PDF uses.
Example questions:
- "How did we close the last quarter compared with the one before: what really got worse, and what is only more coverage?"
- "Show critical and high issues quarter by quarter this year, with the typical time to fix and the share fixed within the deadline."
- "Compare the first half of 2026 with the second half of 2025."
- "Which areas have the most issues past their deadline right now, how old are they, and what should we decide first?"
- "Accepted risk: how many acceptances expire in the next 30 days?"
- "In the September report we had 12 critical issues open. What changed since?"
- "Prepare three points for the board about code and supply chain risk this quarter."
These tools answer only for organizations whose plan includes the Executive Security Report; elsewhere they say so and the guided setup stops the goal with the reason.
Know where you are: the organization, the documentation and what you can do
Three tools of the same read-only server answer the questions an AI client should ask before it works, and they are a good first call in any new chat. They belong to the module Platform, help & capabilities and every goal of the guided setup switches them on; in an existing gateway, switch the module on in the Gateways tab.
| Need | Tool | What it answers |
|---|---|---|
| Who am I working for | get_workspace_context |
The organization behind the connection as WASViking sees it: name, plan and subscription state, the product modules the subscription enables, what is configured (web targets, repositories by provider, hosts and gateways, cloud accounts, edge collectors, monitored domains and certificates), the state of the integrations (ticketing, repository providers, notification channels, SSO), the AI Guardian switches, who is calling (a person or an automation, by key or by sign-in) and the operational limits of the MCP tools. Counts and states only |
| How does WASViking work | search_product_documentation |
The pages of this documentation that answer a question, in English or Brazilian Portuguese: title, section, address, summary and the relevant excerpt. Only released functionality is documented, so an answer that is not here is not a capability of the platform |
| What can I do here | discover_capabilities |
Every tool this connection may call on this gateway right now, with its action class (read, write, destructive), the module it serves, whether a person's approval is expected (always, conditional or none), whether a sign-in needs the write scope and its required arguments (the whole input schema on request); the tools of your organization that are out of reach and why; the modules of the subscription and whether each is enabled |
What never changes:
- The organization is the one behind the credential WASViking validated. None of the three accepts an organization, tenant or workspace identifier, and an argument that names one is refused before anything runs.
search_product_documentationreads the public documentation only, the same for every customer. WASViking keeps no documentation specific to an organization, and the internal documents of the platform are never read.discover_capabilitiesis a reading of what the gateway allows: it grants nothing, enables nothing and runs nothing. Every later call still goes through the policies, the inspection, the approvals and the audit trail.
Example requests:
Before we start, tell me which organization this is, which modules are enabled and what you are allowed to do here.
How does Infrastructure Defense apply updates? Answer from the WASViking documentation and give me the page.
Which of your tools need a person's approval on this gateway?
Step 2: what happens when a scan is asked
| Situation | Answer |
|---|---|
| The URL is not a registered target | target_not_registered: list the targets, or register the target in the portal. The chat never registers a target |
| A scan of the target is in progress | The same scan is returned; nothing new is queued |
| The target finished a scan less than an hour ago | recently_scanned with the scan and the time a new one is allowed; the findings of that scan are current |
| The repository is connected but not monitored | not_monitored: monitoring is turned on in the portal and counts against the contract |
| A project was sent as files (upload or MCP) | upload_required: a new analysis needs the files again (see Analyse a project's code) |
| The plan's scan capacity is in use, or the monthly ceiling of scans asked through MCP was reached | quota_reached: ask later or ask an administrator to raise the capacity |
| The gateway's policies require a person's approval | The call waits in Approvals; the client repeats it after the approval |
Every scan asked this way shows who asked: on Scans, the origin badge reads AI client (MCP); in Code Security, the run history carries Sent by an AI tool (MCP) with the caller.
What never leaves WASViking
The evidence of a finding is handed to the client scrubbed: credentials, cookies, authorization headers, tokens and private keys are removed or redacted, URLs lose their query, long texts are clipped, and the gateway's result inspection still runs on the answer (a gateway set to enforce masks anything that still looks like a secret). Leaked values of Exposure Intelligence never appear, only counts and dates. Code is included only as the lines the detector kept as evidence of the finding.
Step 3: check the trail
Open Calls & Monitoring. Every call appears with the caller, the tool, the decision and the risk context; a scan start shows the class write and, when a policy asked for it, the approval that let it through. Arguments and results are never stored, only their classes, hashes and the decision.