Meanwhile, a CVSS 5.0 three pages down is in active ransomware campaigns. CISA added it to the Known Exploited Vulnerabilities catalog last week. EPSS gives it an 80% exploitation probability. Nobody looked at it because it was page three.

CVSS tells you how bad a vulnerability could be. It says nothing about whether anyone is actually exploiting it. For that, you need two more data sources — and nobody combines all three in one place.

Until now. vulnerability-intelligence-mcp is an open-source MCP server that pulls from NIST NVD, CISA KEV, and FIRST.org EPSS, computes a composite risk score, and gives your AI 30 tools for CVE analysis, watchlist tracking, and scanner triage.

The three data sources

NIST NVD (National Vulnerability Database) is the canonical CVE registry. It tells you what a vulnerability is — the affected products, the CVSS severity score, the weakness type (CWE), and when it was published. This is the "how bad could it be" signal.

CISA KEV (Known Exploited Vulnerabilities catalog) is ground truth for active exploitation. If a CVE is in the KEV catalog, CISA has confirmed that threat actors are exploiting it right now. Not theoretically — actively. The catalog also flags which CVEs are linked to ransomware campaigns.

FIRST.org EPSS (Exploit Prediction Scoring System) is a machine learning model that predicts the probability of a CVE being exploited in the next 30 days. It's trained on real exploitation data and updated daily. An EPSS score of 0.85 means there's an 85% chance this CVE will be exploited in the wild within a month.

Each source answers a different question:

Individually, each is useful. Combined, they tell you exactly what to patch first.

The scoring algorithm

The composite score combines all three sources into a single 0-10 number with a risk tier (CRITICAL, HIGH, MEDIUM, LOW):

base = cvss_base_score if available else 5.0

epss_multiplier = 1.0 + (epss_score * 2.0)

composite = base * epss_multiplier
if in_cisa_kev:
    composite += 2.0
if ransomware_linked:
    composite += 1.0

composite = clamp(composite, 0.0, 10.0)

The logic: start with the CVSS base score, then amplify it by exploitation probability. A high EPSS score can double the effective severity. Active exploitation (KEV) adds a flat +2.0 bonus. Ransomware linkage adds another +1.0. The result is clamped to 10.

Tier thresholds: CRITICAL >= 9, HIGH >= 7, MEDIUM >= 4, LOW < 4.

Any source can be missing — the score degrades gracefully. If NVD has no CVSS data, it assumes 5.0. If EPSS has no score, the multiplier stays at 1.0. If KEV lookup fails, no bonus is added. You always get a usable score.

Why this reranks your scanner output

Consider two CVEs in the same Trivy scan:

CVE-A: CVSS 5.0, EPSS 80%, in CISA KEV, ransomware-linked

• Composite: 5.0 x 2.6 + 3.0 = 16.0, clamped to 10.0 — CRITICAL

CVE-B: CVSS 7.5, EPSS 0.3%, not in KEV

• Composite: 7.5 x 1.006 = 7.55 — HIGH

Your scanner ranked CVE-B higher because CVSS 7.5 > 5.0. The composite score flips the priority: CVE-A is the one in active ransomware campaigns. CVE-B is a theoretical risk nobody is exploiting.

Run it yourself

git clone https://github.com/thinkchainai/vulnerability-intelligence-mcp
cd vulnerability-intelligence-mcp
pip install .
NIST_NVD_API_KEY=your_key vulnerability-intelligence-mcp

CISA KEV and EPSS are public APIs — no additional keys needed. Get a free NVD API key at nvd.nist.gov (takes 30 seconds).

30 tools across five categories

The profile tools make repeated use genuinely useful:

Technology stack profiling — tell the server what you run (nginx 1.24, postgresql 16, ubuntu 22.04). Every subsequent CVE lookup automatically flags whether the vulnerability affects your stack.

CVE watchlist — track specific CVEs over time. The server captures baseline EPSS and KEV status when you add a CVE, then reports deltas on every check.

Scanner triage — paste raw Trivy JSON, Grype JSON, CSV, or any text containing CVE IDs. The server extracts every CVE, scores them across all three sources in parallel, cross-references your technology stack, and returns a prioritized triage report grouped by risk tier.

Example: triage a Trivy scan

Run Trivy against your container image, then hand the output to your AI:

"Triage this scan output: [paste Trivy JSON]"

The scan_triage tool extracts all CVE IDs, queries NVD + KEV + EPSS for each in parallel, and returns:

{
  "total_cves": 47,
  "by_tier": {
    "critical": 3,
    "high": 8,
    "medium": 22,
    "low": 14
  },
  "stack_affected": 2,
  "results": [
    {
      "cve_id": "CVE-2024-6387",
      "composite_score": 10.0,
      "risk_tier": "CRITICAL",
      "rationale": "CVSS base 8.1; EPSS 91.5%; confirmed actively exploited (CISA KEV)",
      "in_your_stack": true,
      "affected_technologies": ["openssh"]
    }
  ]
}

47 CVEs from your scanner, instantly triaged into 3 you need to act on today, 8 you should plan for this sprint, and 36 that can wait.

Architecture

The server is a standard MCP server built with FastMCP. Three async API clients handle the data sources:

• NVDClient — authenticated requests to the NVD 2.0 API
• CISAKEVClient — fetches the KEV catalog (public, no auth)
• EPSSClient — queries the FIRST.org EPSS API (public, no auth)

Profile data (tech stack, watchlist, briefing state) persists to a local SQLite database at ~/.vulnerability-intelligence/state.db.

Use it without installing anything

If you don't want to run the server locally, the same 30 tools are available as a hosted bundle at mcpbundles.com. One URL, works with Claude, ChatGPT, Cursor, or any MCP client.

Source

MIT licensed. PRs welcome.

GitHub: github.com/thinkchainai/vulnerability-intelligence-mcp

But here's what nobody's writing about: MCP works just as well for dispatching tasks to humans.

I've been running a system where my AI orchestrates microtask workers — real people — through the same MCP tool interface it uses to call any other API. The AI creates campaigns, assigns tasks, monitors submissions, validates results, rates workers, and stores outputs. All through standard MCP tool calls. No custom integration. No separate dashboard. The human workforce is just another tool in the AI's toolkit.

The setup

Microtask platforms (Microworkers, Amazon Mechanical Turk, Toloka) have REST APIs. You can create tasks, assign them to workers, pull results, and rate quality programmatically. Building one of these as an MCP tool bundle takes the same effort as building tools for any other SaaS API.

Once you do, your AI gets tools like:

• Create campaign — define a task, set price per completion, specify how many workers you need
• List submissions — pull all worker responses for a campaign
• Rate submission — mark work as accepted or rejected, with feedback
• Get account balance — monitor spend

From the AI's perspective, these are identical to any other MCP tools. It calls them the same way it calls a Stripe API or a database query. The difference is that on the other end, a human does the work.

Why this matters

There's a category of tasks that AI handles badly and humans handle trivially. Signing up for a website. Navigating a UI that has no API. Confirming whether a physical location exists. Reading a CAPTCHA. Verifying that a phone number connects to a real business.

The conventional approach is to either skip these tasks or build brittle browser automation. Both are wrong. The correct abstraction is: route each task to whoever does it best.

Sometimes that's GPT-4. Sometimes that's a Python script. Sometimes that's a person in Nairobi who can complete the task in 90 seconds for $0.30.

MCP doesn't care which. The tool returns a result. The AI consumes it and continues.

What I learned running 300+ human tasks through MCP

Speed surprised me

Workers claim tasks within minutes of posting, not hours. The microtask workforce is global and online around the clock. I post a batch of 50 tasks at 3am my time and have results by breakfast.

Price per task is absurdly low for the right work

Simple tasks (visit a website, find a specific piece of information, paste it back) run $0.20–$0.40 each. More complex tasks (create an account, navigate multi-step flows, take screenshots as proof) run $0.40–$0.60. At these prices, redundancy is cheap — assign three workers to the same task and cross-validate their answers.

Worker quality varies wildly, and that's fine

Some workers are meticulous. Some paste garbage. The key insight is that quality control is a data problem, not a people problem. Track worker IDs across tasks. Build a quality score. Workers who consistently deliver good results get routed more work. Workers who submit garbage get excluded.

After a few hundred tasks, I had a clear tier list:

The exclude list is tiny. Most people do honest work when the task is clear and the pay is fair.

Per-task instructions are everything

My first campaign used generic instructions. Results were noisy — 30% of workers completed the wrong variant of the task because they picked whichever looked easiest. When I switched to unique, specific instructions per task (each worker gets exactly one assignment with step-by-step directions), accuracy jumped dramatically.

The AI generates these per-task instructions. It knows what each task requires, formats the instructions with the right URLs and field names, and submits them as template variables in the campaign creation call. The human gets a clear, unambiguous task. The AI gets a structured result back.

Escape hatches prevent wasted money

Not every task is completable. Sometimes the website requires a credit card. Sometimes the information doesn't exist. Workers need a clean way to say "I can't do this" without getting penalized.

I added explicit escape hatch options to every task: "REQUIRES_CC" and "NOT_AVAILABLE." Workers who correctly identify impossible tasks get rated the same as workers who complete possible ones. This sounds small but it changed the economics — I stopped paying workers to waste time on dead ends, and I stopped rejecting honest workers for reporting real blockers.

The AI handles the whole lifecycle

Here's what a typical batch looks like from the AI's perspective:

1. Select tasks — query a database for items that need human work
2. Generate instructions — create per-task directions from templates
3. Create campaign — call the microtask platform's API via MCP, submit all tasks
4. Wait — sleep, check back periodically (also an MCP tool)
5. Pull results — list all submissions, parse structured answers
6. Validate — test each result against a known-good source (API call, database lookup, HTTP request)
7. Rate workers — accept valid submissions, reject garbage
8. Store results — persist validated data
9. Update state — mark items as complete in the database

Every step is an MCP tool call. The AI doesn't need a human operator to run this loop. It dispatches to humans, validates their work, manages quality, and continues autonomously.

The cost math

Over 300+ tasks across multiple campaigns:

$90 for 300 tasks that would have taken me days to do manually, or would have required building and maintaining fragile browser automation that breaks every time a website updates its UI.

The MCP tool definitions are identical to any other integration — same auth, same structured inputs and outputs, same orchestration. The only difference is that the "compute" on the other end is a human brain instead of a server.

What tasks in your pipeline should probably be done by a human instead of an AI? I'd genuinely like to know — drop a comment with your use case.

Stanford\'s Digital Economy Lab just published The Enterprise AI Playbook — 116 pages of research covering 51 successful AI deployments across 41 organizations. The team is led by Erik Brynjolfsson, one of the most-cited economists on technology. They interviewed executives and project leads who actually deployed AI at scale.

One finding hit differently from the rest.

1,600 tools. One company.

A semiconductor manufacturer ran a security audit and discovered employees were using 1,500 to 1,600 different AI tools across the organization. Not 15. Not 150. Over a thousand.

"When I did the security analysis, we found the company staff are using 1,500 or 1,600 different AI tools. So our objective was building working internal platforms before we go and say you cannot use non-approved tools." — Executive, Semiconductor Manufacturer

And this wasn\'t a rogue engineering team. Leadership had told people to "use AI" — but provided no approved platform to use. Enthusiasm outpaced governance.

The numbers are worse than you think

The Stanford study cites industry data that\'s hard to ignore:

• 70-80% of employees who use AI at work rely on tools not approved by their employer
• Only 22% use exclusively company-provided tools (IBM/Censuswide, 2025)
• 57% admit to entering sensitive company information into unauthorized AI platforms
• AI-associated data breaches cost organizations an average of $4.88M per incident — the highest of any breach category (IBM Cost of Data Breach Report)

Shadow AI was explicitly mentioned in 15% of the case studies. The researchers found two distinct patterns:

Pattern A: Enthusiasm outpaces governance. The semiconductor company above. Leadership says "use AI," provides no sanctioned tooling, and people find their own.

Pattern B: Desperation beats bureaucracy. In healthcare, physicians adopted ambient transcription tools without formal approval because hospital procurement processes took too long. Doctors were burned out, the technology existed, and the formal process was measured in quarters while their pain was measured in hours.

"A lot of these doctors have been adopting these technologies without approval or a formal vendor selection process." — Executive, Healthcare AI Company

Shadow AI is a symptom, not the disease

This is the insight that most security teams miss. The Stanford researchers are explicit:

Shadow AI is a symptom that policy moves slower than technology, and it needs to be expected but accounted for.

Blocking access doesn\'t work. People route around restrictions when the pain is acute enough. The organizations that solved this didn\'t solve it with stricter policies. They solved it by building internal platforms fast enough that shadow tools became unnecessary.

The report draws a sharp line:

• When security investment makes sense: When it enables use cases that would otherwise be impossible — handling customer financial data, processing healthcare records, managing confidential M&A documents.
• When security investment is wasteful: When formal processes are too slow and shadow AI fills the gap, creating exactly the security risks the process was designed to prevent.

That second point is worth sitting with. The security process designed to prevent data leaks causes data leaks by pushing people to unvetted tools.

This maps to what I see building developer tools

I build an MCP platform that connects AI assistants to real services — Stripe, HubSpot, Postgres, Shopify, and about 130 others. The pattern repeats constantly: a developer wants AI to access their company\'s CRM, IT hasn\'t approved anything, so they paste customer data into ChatGPT. The data lands in OpenAI\'s systems with no audit trail. The fix is providing a governed channel — proper auth, scoped permissions, audit logging — so they never need to copy-paste.

What actually works (from the 51 that succeeded)

Every successful deployment in the Stanford study used an iterative approach. 100%. No waterfall. Start small, learn, expand. Two-thirds had significant failed attempts before their current success.

The ones that moved fastest shared three accelerators:

For security specifically, the report found that the upfront investment is real but front-loaded. Once the infrastructure exists — data scrubbing pipelines, cloud provider contracts, compliant archival systems — each new AI use case builds on that foundation instead of starting from scratch.

MIT\'s NANDA initiative reinforces this: 95% of generative AI pilot programs fail to produce measurable financial impact, and the failures come from poor workflow integration — not model quality. Every stalled pilot creates demand pressure that feeds shadow AI adoption.

The question for your team

If you ran a security audit of AI tools in your organization right now, what number would you find?

Not the tools IT approved. The tools people are actually using. The Chrome extensions. The API calls to Claude from personal accounts. The screenshots pasted into ChatGPT. The VS Code extensions that send code to who-knows-where.

The Stanford researchers\' conclusion applies here:

"The window for experimentation is closing. The question is no longer whether AI will deliver value. It is whether organizations can evolve fast enough to capture it."

Shadow AI is what happens when organizations can\'t evolve fast enough. The tools exist. The demand exists. The only question is whether access happens through governed channels or ungoverned ones.

Data and quotes from The Enterprise AI Playbook by Elisa Pereira, Alvin Wang Graylin, and Erik Brynjolfsson, Stanford Digital Economy Lab, April 2026. 51 case studies, 41 organizations, 7 countries.