PDQ Connect MCP

Show me devices without Chrome installed in PDQ Connect in an interactive table

What Firefox packages are in PDQ Connect?

Create a dashboard of devices without Firefox or Chrome in PDQ Connect that I can share with my IT Director

Could you add Chrome to any device that doesn't have it?

A longer, copy-and-paste prompt that has your assistant pull live fleet data from PDQ Connect, cross-reference the latest Patch Tuesday CVEs from the web, and produce a self-contained interactive HTML report.

You are helping me build an interactive "Patch Tuesday impact" report for my PDQ Connect
organization. Use my connected PDQ Connect tools for all device data and the web for CVE data.
Be pragmatic and accurate. Never invent numbers; if you can't measure something, say so.

STEP 1 - GET THE CVEs
- Web-search the most recent Microsoft Patch Tuesday and its notable CVEs (count, how many
  Critical, any zero-days or actively-exploited flaws, and the headline RCE/EoP CVEs).
- Patch Tuesday is the second Tuesday of the month. If the newest one has no published CVE
  data yet, use the most recent release that does and tell me which month you used.

STEP 2 - MEASURE MY FLEET (exact counts, not estimates)
Use search_devices. The base device row includes os, os_full_name, os_version (build),
require_reboot, and last_checkin_time. Tips that keep this accurate:
- search_devices caps at 250 rows. To get an exact COUNT for any segment, run a filter with
  limit:1 and read the "total_count" field. That's the reliable way to size each group.
- Get these totals:
  * Whole fleet: total devices.
  * By OS: macOS vs Windows clients (os_full_name contains "Windows 11"/"Windows 10")
    vs Windows Server (os_full_name contains "Server"), and each server version.
  * Pending reboot (exact, very actionable): filter devices[require_reboot]=true
  * Stale / unreachable: filter  devices[last_checkin_time] relative more than 7 days ago
  * Patch level by build: the current cumulative shows up as the highest build revision in
    the fleet for each Windows family (the 4th number, e.g. 26100.XXXX). Count how many are on
    the latest revision vs behind. Find the top revision present, then count devices below it.

STEP 3 - SCORE AND PRIORITIZE
- Map the headline CVEs to my fleet (e.g. a kernel/TCP-IP RCE touches every Windows device;
  HTTP.sys and Defender flaws are server-weighted; RDP-client RCEs hit admin workstations).
- Build a remediation order by blast radius. Usually: reboot-pending servers first (the fix is
  already staged, just needs a restart), then any actively-exploited flaw on isolated hosts,
  then rolling the latest cumulative to behind clients, then chasing stale devices back online.

STEP 4 - BE HONEST ABOUT LIMITS
State these plainly in a methodology footer:
- Patch level is INFERRED from OS build revision, not per-CVE/KB state.
- require_reboot and last_checkin are exact (straight from Connect).
- The MCP does not expose installed-software inventory, so app CVEs (SharePoint, SQL, Office)
  can't be confirmed per device here; note they'd need the Connect REST API or a software report.
- Name which Patch Tuesday month the CVE data is from.

STEP 5 - OUTPUT: a single self-contained interactive HTML file
Include: a KPI row (devices behind, pending reboot, on latest build, stale), a fleet posture
bar, filterable/expandable CVE cards each showing my exposure count, a prioritized remediation
queue, a server breakdown, and the methodology footer. Use vanilla JS only, no external libs
except Google Fonts. No localStorage.

LIGHTWEIGHT PDQ BRANDING (apply to the HTML)
- Dark theme. Page background #131515, panels/cards #1F2121, hairline borders ~#33393a.
- Body text white at ~85% opacity; never pure black or pure white. Muted text ~#8a9290.
- Headers in Space Grotesk, body in Inter, both from Google Fonts.
  Fallbacks: Lato for headers, Roboto for body.
- Accent color: teal #0A95E6 (or a brighter mint #5CDBBF) for highlights, links, key numbers.
- Status colors: success #007D54, warning #FF9933, error/critical #ff6b5e.
- Put PDQ's signature rainbow bar as a thin top stripe: five equal-width segments left to right,
  #FF9933, #FFFF33, #99CC33, #A2FFD4, #0099CC.
- Left-align text. Bold for emphasis only. Underline only for links. Don't rely on color alone
  to convey meaning.
- Don't recreate the PDQ logo; a plain "PDQ Connect" wordmark set in Space Grotesk is fine.

While the current toolset is limited, we’re excited to continue building out functionality and providing more tools.

Interested in a specific tool and/or workflow? Let us know here (link).

The PDQ Connect MCP server enforces the exact same permissions as the Connect console. When you authenticate via OAuth, the MCP server acts as you and inherits your role and permissions. It cannot grant any additional access.

This means:

• Every action taken through MCP is checked against your account’s permissions, just as it would be in the console.
• You can only see and act on the devices, packages, groups, and other resources your account already has access to.
• If you lack permission to perform an action in the console (for example, deploying a package), that same action will be denied via MCP.
• MCP is not a way to bypass or escalate permissions. It is simply another interface to the access you already have.

With the introduction of MCP, we’re enhancing our Audit Logs to provide better visibility into where and how actions were performed. The Audit Logs now include Source and Client columns.

So when an action is performed via MCP, we’ll log the Source as MCP and the Client based on where the request was sent from (e.g., Claude Code).

Authentication issues

• Make sure you complete the OAuth flow when prompted.
• Try disconnecting and reconnecting: look for a “Clear authentication” or “Disconnect” option in your tool’s MCP settings.