Webroot MCP server and AI skills

What it can do

• Sites & fleetThe shape of the console: what it is, which client sites hang off it, and the headline protection, DNS and training numbers at both levels.10skills

  Reading only — no site is created, renamed, suspended, or deactivated, and no keycode is issued from here. The per-site figures are fetched a site at a time because Webroot exposes no batched form of them, so a fleet-wide roll-up is many calls rather than one, and on a very large console it is answered progressively rather than instantly.

  • The console itself at a glance — what this GSM is called, the keycode behind it, and the status it's in.
  • Every client site under the console in one pass, each with its keycode, site id, status and device count.
  • One site's record opened in full, pulled straight by its site id.
  • Turn the keycode written on a client record into the site id the rest of this surface asks for — the translation step between console-speak and everything else.
  • Protection counted across the whole console: how many devices, how many threats, and how the protection states break down.
  • The same protection breakdown narrowed to a single client site — one call per site, since there's no way to ask for several at once.
  • DNS Protection measured console-wide — requests seen, requests blocked, and how much of the fleet is actually covered.
  • That same DNS coverage picture for one client, which is the version worth putting in front of them.
  • Security Awareness Training across the console: how many campaigns ran and how many people finished them.
  • Training campaign and completion figures for a single site on their own.
• EndpointsThe machines themselves: what's on each site, how they're grouped and which policy they answer to, whether their agents are live right now, and what has been commanded at them.9skills

  Nothing here touches a machine. No scan is started, no agent reinstalled or uninstalled, no endpoint moved between groups, and no command is issued — the command tools read a history that something else wrote. Site-scoped lists want a site id, so a keycode is resolved through the site lookup first. Endpoint lists are paged; the two SkyStatus tools ignore paging entirely and hand back roughly fifty records at a time with a continuation token to collect the rest.

  • The machines on a site — device name, protection status, OS, last seen — a page at a time, because a large site doesn't come back in one response.
  • A single machine in full: hostname, OS, whether it's protected, and when it last checked in.
  • How a site's endpoints are grouped, and which policy each group is pointed at.
  • One group on its own — its name, the policy assigned to it, and how many machines sit inside.
  • The actual membership of a group, machine by machine.
  • Live agent status from SkyStatus for every endpoint under the console — online or not, last contact, agent version — narrowable to one machine or to records changed since a timestamp, and collected in ~50-record batches via a continuation token.
  • The same live check aimed at the DNS Protection agent rather than the endpoint agent, batched and continued the same way.
  • What has been commanded across a site and how it went — type, target, status, timestamp. A record to read, never a place to send one.
  • The command history for one machine, which is where 'did that ever actually run?' gets settled.
• Threats & securityWhat Webroot caught and what it stopped: threat history at site, group and machine depth, plus Web Threat Shield's record of blocked URLs.5skills

  It reports detections; it cannot act on them. No file is quarantined or restored, no threat marked reviewed, no scan triggered, and no URL added to an allow or block list. History is fetched per scope with an optional date window — there is no console-wide 'every threat everywhere' call, so a fleet answer is built site by site.

  • Everything caught across one site over the window you name — the threat, the action taken against it, and when.
  • The same record narrowed to a single group of machines, for when one department keeps showing up.
  • One machine's detections on their own — the answer when a single user seems to attract everything.
  • Web Threat Shield totals day by day for a site: the shape of the trend before you go looking at rows.
  • The rows behind those totals — which URL, what action was taken, on which endpoint, at what time.
• DNS ProtectionThe DNS layer end to end: the categories policies are built from, the policies themselves, where each one is applied, and the traffic that resulted.9skills

  Policies and mappings are readable and never writable — no category is toggled, no allow or block list edited, no policy created or pointed at a different network. Site traffic reports take an optional date window; only the traffic summary spans every site in one call, so the detailed views are still per-site.

  • The category vocabulary a DNS Protection policy is built out of — what can be blocked or allowed in the first place.
  • Every DNS Protection policy defined on the console, with its id, name and the category rules it carries.
  • A single policy read out in detail, down to its allow and block lists.
  • Which policy governs which network or group at a site — the wiring between a policy and the people it applies to.
  • The block-reason list the traffic reports are written in, so a blocked row can be read rather than guessed at.
  • The individual requests DNS Protection stopped at a site — domain, category, reason and timestamp, over a window you choose.
  • A site's DNS requests totalled up by category — where the browsing actually goes, which is worth knowing even when nothing was blocked.
  • Requests and blocks for every site under the console side by side — the one DNS view that answers fleet-wide in a single call.
  • Those same two figures for one site, when only that client is in question.
• Admins & policiesWho can get into the console and what the endpoint protection policies are set to — the governance layer behind everything else.6skills

  Read-only in both halves. No admin is invited, promoted, demoted, or removed, and no site access is granted; no policy is created, edited, copied, or assigned to a group. What comes back is the current configuration, which is the evidence for a change someone else then makes in the console.

  • Who holds a login on the GSM console, with their id, name, email and role.
  • One admin opened up — role included, and the sites that account can actually reach.
  • The admin accounts attached to a single site, which is how you check who at a client can log in.
  • The global endpoint protection policies the console defines, by id, name and description.
  • One policy's settings in full — the record of what it is genuinely configured to do, not what it was named.
  • Which of those policies a given site has available to it.
• Usage reportingThe billing-shaped view: licensing and endpoint counts for the console, per site, and per machine.3skills

  Webroot keeps roughly forty days of usage-report history upstream, so a window older than that comes back empty or short rather than reconstructed — for a longer trend you need your own periodic snapshot. These are point-in-time totals as of the report's effective date, not a log of activations, deactivations, or seat changes over time.

  • Where the console stands on its report date — license type and expiry, total sites and endpoints, trial split from paid. A snapshot, not a history of how it got there.
  • Endpoint usage summarised site by site across the console — the figures a billing conversation runs on.
  • The same usage counted machine by machine, paged so a big console can be walked through rather than swallowed whole.
• Agent & sessionWhat this connection is and whether the platform behind it is up — the two things to check first when an answer looks wrong.1skills

  Read-only, and it reports the connection rather than repairing it: it cannot re-enter credentials, swap the GSM keycode, or mint a fresh token. A console login that has had 2FA switched on, or a rotated Unity API secret, shows up here as a connection that has stopped validating — fixing it means reconnecting.

  • Whether the Webroot Unity API is answering at all and which version is running, merged from its own ping and version checks — the first thing to try when everything fails at once.
• DNS Protection, more5skills
  • Dnsp mapping.
  • DNS Protection traffic summary grouped by category, GSM-wide across every site under the console.
  • Site dnsp traffic summary category report.
  • DNS Protection traffic summary grouped by category and by user, GSM-wide across every site under the console.
  • Site dnsp traffic summary category user report.
• Fleet more2skills
  • CRSB (OTSB) statistics for the whole GSM console: device counts, threat counts, coverage.
  • Site crsb stats.
• Reporting more24skills
  • Usage site.
  • Usage site endpoints.
  • GSM-level summary report of DNS Protection (DNSP) usage.
  • Site-level summary report of DNS Protection (DNSP) usage across every site under the GSM.
  • Site-level summary report of DNS Protection (DNSP) usage for one site by keycode.
  • GSM-level summary report of WSAT (Security Awareness Training) usage.
  • Site-level summary report of WSAT usage across every site under the GSM.
  • Site-level summary report of WSAT usage for one site by keycode.
  • Partner-level summary usage report for Pillr (MDR), keyed by partnerKeycode.
  • Customer-level summary Pillr usage report for a partner.
  • Pillr usage report for one customer by customerKeycode under a partner.
  • Endpoint-level Pillr usage report for one customer under a partner.
  • GSM-level summary usage report for Detection and Response.
  • Site-level summary Detection and Response usage report across every site under the GSM.
  • Site-level Detection and Response usage report for one site by keycode.
  • Endpoint-level Detection and Response usage report for one site by keycode.
  • GSM-level summary usage report for OTSB (CRSB).
  • Site-level summary OTSB (CRSB) usage report across every site under the GSM.
  • Site-level OTSB (CRSB) usage report for one site by keycode.
  • Endpoint-level summary OTSB (CRSB) usage report across the GSM.
  • Endpoint-level OTSB (CRSB) usage report for one site by keycode.
  • Partner-level summary usage report for Cloudally (backup), keyed by partnerKeycode.
  • Customer-level summary Cloudally usage report for a partner.
  • Cloudally usage report for one customer by customerKeycode under a partner.
• SkyStatus2skills
  • Site endpoint status.
  • Site dnsp agent status.
• Security awareness training2skills
  • Wsat phishing activity.
  • Wsat training activity.

How it has been taught to work it

Playbooks are the vetted techniques a session loads for this platform — what to check, in what order, and what a number means before it is reported.

• DNSP review — blocked DNS traffic by category and siteDNS Protection questions — what is being blocked, which categories, which sites have DNSP traffic, DNSP policy or coverage review.
  Vetted Aug 11, 2026
• Infection sweep — active threats across sitesAre any machines infected, what threats were seen, malware/virus questions for one client or the whole fleet, "anything nasty this week".
  Vetted Aug 11, 2026
• Querying Webroot — ids, the two paging regimes, and where the docs lieAlways when Webroot is attached. The two incompatible paging regimes, and the live-verified call rules.
  Vetted Aug 31, 2026Always on
• Quiet endpoints — agents not seen in N daysWhich Webroot agents have gone quiet or not checked in for N days, stale/dead agent hunting, "is the AV actually reporting" hygiene questions.
  Vetted Aug 11, 2026
• Usage report — seats seen vs seats licensedLicense/seat questions — how many Webroot seats are we using vs paying for, per-site usage, over/under-deployment, license expiry, billing-shaped Webroot questions. Also DNSP/WSAT/Pillr/Detection & Response/OTSB(CRSB)/Cloudally usage-report questions.
  Vetted Aug 11, 2026
• Webroot domain model (endpoint protection, not an RMM)Always when Webroot is attached. Its domain model, and why it is endpoint protection, not an RMM.
  Vetted Aug 31, 2026Always on
• WSAT campaign activity — who clicked, who finished trainingPer-recipient WSAT questions — who clicked or reported a phishing simulation, who has or hasn't completed security-awareness training, follow-up by name after a campaign.

Plus 18 more every session carries regardless of platform — how to shape an investigation, keep every number traceable, and say plainly when something is broken.