**Disclaimer:** This is an independent, self-built project and is not an official Microsoft tool or service. It reads public security-update data and is intended as an educational example of building an MCP server, hosting it responsibly on Azure, and evaluating an agent workflow with Microsoft Foundry.
By Jon Butler
The monthly Patch Tuesday question
Every Patch Tuesday starts with the same deceptively simple question: what should I patch first?
For anyone responsible for a Microsoft estate, that question quickly breaks into a dozen smaller ones. Which vulnerabilities are Critical? Which ones are already being exploited? Which ones affect Windows Server, Exchange, SharePoint, Microsoft Office, Microsoft Edge, or the identity stack? Which KBs map to which CVEs? Has Microsoft published mitigations or known issues? If two vulnerabilities are both important, which one is more likely to be weaponized in the near term? And how do you turn all of that into a briefing that is accurate enough for security teams but readable enough for leadership?
The authoritative source for this information is the Microsoft Security Update Guide, backed by the public MSRC CVRF API. It is comprehensive, but during a monthly triage window I often want something more conversational: the ability to ask an assistant the same practical questions I would ask a security analyst sitting next to me.
That was the motivation for building patch-tuesday-mcp: an open-source Model Context Protocol server that connects AI assistants to Microsoft Patch Tuesday data and helps turn a monthly security release into a prioritized triage conversation.
This post is not a product announcement. It is a build story: why I modeled the data the way I did, how the MCP server is structured, how I used Azure Container Apps for a hosted test endpoint, and how I evaluated the agent workflow with Microsoft Foundry.
The manual triage problem
Before building anything, I mapped the manual workflow. That exercise was useful because it made the real problem visible.
One example of a manual triage workflow might start at the Security Update Guide, export or read the CVE list, repeat lookups for relevant CVEs, check CISA KEV for known exploitation, pull EPSS scores from FIRST.org, map KBs back to products and fixed builds, check support.microsoft.com for known issues, then sort the results by urgency and write a briefing. Not every team works this way, but it is a representative pattern: repeated lookups across multiple sources, with plenty of opportunities to lose context along the way.
The goal of the MCP server was not simply to automate a lookup. It was to collapse that workflow into a tool an assistant could call repeatedly and reliably: one place to ask release-level questions, product-level questions, KB-level questions, and briefing-generation questions without losing the Patch Tuesday context.
Why MCP was a good fit
The Model Context Protocol (MCP) gives AI assistants a standard way to call external tools and work with external data. Instead of asking a model to reason from stale training data or pasted-in tables, an MCP client can call a tool that retrieves current information, applies domain-specific logic, and returns structured results.
Patch Tuesday is a natural fit for that pattern. The data changes every month. The questions are repetitive but nuanced. And the right answer often depends on several signals at once: severity, CVSS, Microsoft exploitability assessments, affected product families, KB relationships, CISA KEV status, and exploitation probability.
With an MCP server in the loop, a user can ask questions like:
- “Summarize this month’s Patch Tuesday.”
- “Which Critical CVEs affect Windows Server 2022?”
- “Which vulnerabilities are on the CISA KEV list?”
- “Show me network-reachable critical vulnerabilities with no user interaction.”
- “Which CVEs does KB5094123 fix?”
- “Is this KB superseded by a newer update?”
- “Give me a Markdown briefing I can send to my team.”
The source of truth remains MSRC. The MCP server simply makes the public data easier to query, summarize, and prioritize from the tools security teams already use.
Modeling the release, not just the CVE
The most important design decision was to model a Patch Tuesday release rather than a standalone CVE lookup.
There are already many tools that can answer “tell me about CVE-2026-xxxxx.” That is useful, but it is not the complete monthly workflow. Patch teams usually start from a release month, a product estate, and a deployment plan. They need to understand the shape of the release before drilling into one vulnerability.
That led to a release-centric model:
| The question you actually have | Generic CVE lookup | patch-tuesday-mcp |
|---|---|---|
| “Summarize this month’s Patch Tuesday” | No concept of a monthly release | Release rollup, severity counts, affected products, and prioritized results |
| “What Critical CVEs affect Windows Server 2022?” | Often requires manual filtering | Product and product-family filters built in |
| “Which vulnerabilities does this KB fix?” | Usually no KB awareness | KB-to-CVE and CVE-to-KB mapping |
| “What is already being exploited?” | Per-CVE lookup only | Month-wide exploited and KEV filters |
| “What should I patch first?” | Leaves prioritization to the user | Urgency sorting across KEV, exploited, EPSS, severity, and CVSS |
| “What changed over the last few months?” | Usually out of scope | Historical month ranges and trend counts |
Under the hood, that means parsing the full MSRC CVRF monthly documents: the ProductTree, per-product severity data, remediation entries, KB metadata, exploitability assessments, and revision history. That structure is what lets the server answer the questions administrators and analysts actually ask during a patch cycle.
The data correlation is the heart of the project. MSRC provides the monthly release, CVE details, product relationships, and KB remediation data. CISA KEV and EPSS join by CVE ID. Known issues and supersedence information join through KB articles. Once those relationships are modeled, the assistant can move naturally from “what shipped this month?” to “what affects my estate?” to “what should I patch first?”
The data sources
The server combines four public, keyless sources:
- **MSRC CVRF v3 API** – the authoritative Microsoft security update data source.
- **EPSS from FIRST.org** – a probability score estimating whether a vulnerability is likely to be exploited in the next 30 days.
- **CISA Known Exploited Vulnerabilities catalog** – a public catalog of vulnerabilities known to be exploited in the wild, including due dates and remediation guidance for covered federal agencies.
- **Microsoft KB support pages** – best-effort known-issues and supersedence context for update packages.
I wanted the default setup to be as close to frictionless as possible. There are no API keys, no tenant permissions, no service principals, and no account setup. For local use, it is one command:
uvx patch-tuesday-mcpHosted MCP endpoint:
https://patch-tuesday-mcp.agreeabledesert-d0b8e491.eastus2.azurecontainerapps.io/mcpFrom there, any MCP-capable client can connect over stdio and start asking questions.
Keeping the tool surface small
One thing I learned quickly: with AI tools, fewer, better tools are easier for the assistant to use than many narrow tools.
It would have been tempting to expose separate tools such as search_cves, lookup_kb, get_kev, get_epss, list_products, and export_report. Instead, the server exposes one primary tool: msrc_search.
That single tool can handle:
- monthly release summaries;
- CVE lookups;
- KB lookups;
- product and product-family filtering;
- severity and CVSS filtering;
- EPSS thresholds;
- CISA KEV filtering;
- exploitation-likelihood filtering;
- known-issues enrichment for KBs;
- guidance and mitigation lookups;
- historical ranges;
- Markdown or CSV briefing output.
For an MCP client, that keeps the decision tree simple. The assistant does not need to pick from a large tool catalog. It calls msrc_search with the right parameters, and the server applies the Patch Tuesday domain model behind the scenes.
This is also good MCP design hygiene. Every tool definition is additional context the client may need to load, reason over, and choose from. A large tool catalog can create context-window pollution and make tool selection less reliable, especially when several tools appear to overlap. A single well-scoped tool with clear parameters kept the interface smaller and made the agent behavior easier to evaluate.
The server also includes a guided MCP prompt named monthly_triage. The prompt walks through a practical analyst sequence: start with publicly disclosed or exploited vulnerabilities, check KEV, isolate high-risk Critical issues, filter to relevant product profiles, and then produce a briefing. I also packaged the same workflow as a portable Markdown skill so it can be reused by agents that support skills independently of MCP prompts.
Local by default, remote when useful
The default transport is stdio, because local use should be private and simple. In that mode, the server runs on the user’s machine, talks to public data sources, and does not expose a network endpoint.
For shared scenarios, the same server can run over streamable HTTP:
MCP_TRANSPORT=http MCP_PORT=8000 patch-tuesday-mcpThat opened the door to hosting a remote instance on Azure Container Apps. Container Apps fit the project well because the service is stateless, containerized, and mostly idle between requests. The HTTP endpoint includes a /health route for liveness and can scale without session affinity.
The hosted endpoint is intentionally simple: it serves public data and requires no account. For production enterprise use, I would still recommend placing an authenticated front door in front of it – for example Azure API Management, an OIDC-aware proxy, or another gateway that matches your organization’s standard access pattern. The MCP server itself deliberately does not invent its own authentication model.
Test architecture: grounding the agent
For the test setup I built in Microsoft Foundry, I kept the agent intentionally constrained. The agent reaches the Patch Tuesday MCP server over HTTP; the MCP server reaches only the public sources it needs: MSRC APIs, EPSS, CISA KEV, and Microsoft KB pages. The agent is not browsing the open web.
That constraint matters. It keeps the answers grounded in trusted security-update sources instead of letting unrelated web context bleed into the response. It also makes evaluation easier: if the agent answers a Patch Tuesday question, the answer should be traceable to the MCP tool and the public data behind it.
The pattern is simple but useful:
- A user asks the Foundry agent a Patch Tuesday triage question.
- The agent calls the MCP server over HTTP.
- The server retrieves and correlates MSRC, EPSS, KEV, and KB data.
- The agent turns the structured result into a concise answer or briefing.
For enterprise scenarios, I would still put standard platform controls around the hosted MCP endpoint. The test architecture focused on the server and evaluation path rather than defining every consumer’s agent environment.
Operating a hosted MCP endpoint responsibly
Even when an endpoint only serves public data, running it on the internet changes the engineering bar. I did not want the hosted endpoint to be treated as “just a sample” simply because the upstream data is public.
The principle was to use normal production-minded controls without turning the project into a full enterprise gateway:
- keep the endpoint stateless and simple to scale;
- avoid accepting more input than the tool actually needs;
- put reasonable boundaries around resource usage;
- separate local/private stdio usage from shared HTTP usage;
- expose enough health and operational signals to know whether the service is behaving as expected;
- rely on an authenticated front door or gateway for enterprise deployments rather than inventing custom authentication inside the MCP server.
Those controls are not glamorous, but they are the difference between “it works on my machine” and “I am comfortable putting this behind a public URL.”
Evaluating the agent in Microsoft Foundry
Microsoft Foundry is Microsoft’s platform for designing, building, deploying, and operating AI apps and agents. For this project, the important part was that Foundry gave me a managed place to wire up an agent, connect it to a tool, and observe how it behaved against realistic security-triage questions.
Foundry evaluations are the testing layer for those AI apps and agents. They let you run repeatable test cases and score the results with a mix of deterministic checks and AI-assisted quality judges, so you can test not only whether an answer sounds good, but whether it is grounded, relevant, safe, and using tools correctly.
Building the tool was only half the exercise. I also wanted to know whether an agent using it behaved reliably.
For that, I used an expanded Microsoft Foundry evaluation suite against the July 2026 Patch Tuesday release. I deliberately chose a large monthly release so the agent had to reason over a broad set of security-update data rather than a small toy sample. The suite ran 16 queries across 4 runs and passed all 4 runs. The important result for me was not just that the answers looked good; it was that the evaluation found zero fabricated identifiers and no server defect.
The evaluation suite covered three categories:
| Test suite | Purpose | Result |
|---|---|---|
| Deterministic checks | Hard, judge-proof guarantees: always call `msrc_search`, never fabricate CVE or KB IDs, use the correct parameters | 16 / 16 items passed |
| Foundry quality judges | LLM-graded answer quality and tool use: groundedness, tool selection and accuracy, intent, and relevance | All 8 gating evaluators passed across the judged cases |
| Adversarial and safety checks | Resist prompt injection and handle nonexistent-KB traps honestly | Injection attempts were resisted; 4 / 4 nonexistent-KB traps were handled |
The deterministic checks were the most important. For security workflows, a polished answer is not enough. The agent must not invent CVEs. It must not invent KBs. It must call the tool when the task requires current Patch Tuesday data. And when a user asks about a nonexistent KB, the agent should say it cannot find it instead of trying to be helpful by making one up.
The Foundry quality judges added a second layer: groundedness, relevance, intent understanding, and tool-use quality. Those are helpful for catching cases where the answer is technically sourced but poorly framed, incomplete, or misaligned with the user’s actual ask.
The adversarial checks were intentionally practical. I wanted to know whether prompt-injection phrasing could pull the agent away from the tool, and whether nonexistent-KB traps would produce fabricated update guidance. The suite passed those cases, which gave me more confidence that the architecture was doing what I intended: keeping the agent grounded in the MCP server and the trusted public data sources.
Privacy choices
Privacy was another area where I wanted the defaults to be boring in the best possible way.
For local stdio usage, there is no telemetry path. The server runs locally and does not send usage data anywhere.
For the hosted endpoint, telemetry is intentionally minimal and anonymized. It records operational signals such as latency, result counts, error categories, and which parameter names were used. It does not record request bodies, response bodies, query text, CVE values, KB values, account information, or cookies. Client IPs are used briefly for abuse protection and stored only as a daily-salted hash. Retention is limited to 90 days.
That balance gives enough information to understand whether the hosted endpoint is healthy without turning a security tool into a data collection surface.
What the assistant experience looks like
After adding the server to an MCP client, the experience becomes conversational. A user can ask:
“Summarize this month’s Patch Tuesday and call out anything already exploited.”
The assistant can call the tool, retrieve the current released month, enrich the results with EPSS and KEV data, and return a prioritized summary. If the next question is:
“Only show me Windows Server and identity-adjacent products.”
The assistant can narrow the same release to the products that matter for that environment. If the follow-up is:
“Turn that into a Markdown briefing for leadership.”
The same tool can return a formatted report instead of raw JSON.
That is where MCP is most useful: not as a novelty layer, but as a way to let the model orchestrate real, current, domain-specific operations.
Lessons learned
There were a few takeaways I would carry into any future MCP project:
Model the workflow, not just the API. The MSRC API is rich, but users do not think in API documents. They think in releases, products, KBs, and patch plans.
Prefer one capable tool over many tiny tools. A smaller MCP surface made the assistant more predictable and reduced context-window pollution from a long list of overlapping tool definitions.
Ground the agent deliberately. For the Foundry demo, the agent reached only the MCP server. That made the behavior easier to reason about and evaluate.
Evaluate for accuracy, not just fluency. Especially in security workflows, a polished answer that invents a CVE or KB number is worse than no answer. The evaluation needs to check that identifiers, tool calls, and claims are grounded in the source data.
Make the first run effortless. Public, keyless data and uvx mean the user can try it before committing to anything.
Treat public test endpoints like production. Resource boundaries, observability, and telemetry minimization should be part of the first version, not cleanup work later.
Be explicit about what the tool is and is not. This is an independent helper over public data. The source of truth remains MSRC.
Try it yourself
Local install:
uvx patch-tuesday-mcpThe project includes setup instructions for VS Code, GitHub Copilot CLI, Cursor, Claude Code, and Claude Desktop. It can also run as an HTTP MCP endpoint in a container if you want to self-host it on Azure Container Apps.
Links:
- GitHub: https://github.com/jonnybottles/patch-tuesday-mcp
- PyPI: https://pypi.org/project/patch-tuesday-mcp/
- MCP Registry: `io.github.jonnybottles/patch-tuesday`
If you build MCP servers, security automations, or internal triage tooling, I hope the design notes are useful. Patch Tuesday is a recurring operational problem, and MCP turned out to be a practical way to make that workflow easier to ask about, easier to automate, and easier to explain.