Security Intel MCP

Name: Security Intel MCP
Author: datakoot

Server Details

CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 32 days
Last Tested: 2026-10-07 17:36
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: datakoot/security-intel-mcp
GitHub Stars: 0
Server Listing: Security Intel MCP

TDQS

A3.9/5.0

Scored 2026-10-03 19:40 across 5 tools

Disambiguation4/5

Most tools target distinct needs, but there is meaningful overlap: cve_lookup already bundles EPSS score and KEV status, which epss_score and known_exploited provide separately, and audit_dependencies vs package_vulnerabilities both surface package vulns (manifest vs single package). The distinctions are documented and defensible, but an agent could reasonably pick the wrong one.

Naming Consistency4/5

All names use snake_case, which is consistent, and each is readable and descriptive. The style drifts between verb_noun (audit_dependencies) and noun_noun/adjective (cve_lookup, epss_score, package_vulnerabilities, known_exploited), so the pattern is not perfectly uniform.

Tool Count5/5

Five tools is well within the healthy 3-15 range and each earns its place, covering a focused vulnerability-intelligence surface without redundancy that bloats the set.

Completeness4/5

The surface covers the core security-intel lifecycle: single CVE detail, exploit probability, known-exploited status, per-package vulns, and whole-manifest auditing. Minor gaps exist, such as no keyword/vendor CVE search or bulk advisory listing, but core workflows are covered.

Available Tools

5 tools

audit_dependenciesAudit DependenciesA

Read-onlyIdempotent

Inspect

Audit a whole dependency manifest for known vulnerabilities in one call. Paste a package.json (as 'manifest'), or pass a 'dependencies' array of {name, version} objects. Returns per-package findings and a summary. Ecosystem defaults to npm.

ParametersJSON Schema

Name	Required	Description
`manifest`	No	Raw package.json contents
`ecosystem`	No	Package registry for the dependencies: npm (default), pypi, cargo, go, maven, rubygems, nuget, composer, pub, or hex.
`dependencies`	No	[{name, version}] entries

Output Schema

ParametersJSON Schema

Name	Required	Description
`source`	No
`verdict`	No
`findings`	No
`ecosystem`	No
`packages_audited`	No
`packages_not_found`	No
`packages_unverified`	No
`total_vulnerabilities`	No
`packages_with_vulnerabilities`	No

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the return shape ('per-package findings and a summary') and the npm default, but discloses no auth requirements, rate limits, or behavior when both inputs are supplied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each carrying distinct information (purpose, input modes, default). The core purpose is front-loaded and nothing is redundant with the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only audit tool with full schema coverage and an output schema, the description supplies what the agent needs: purpose, both input modes, ecosystem default, and a hint at the return shape. Only the ambiguous both-inputs case and any size/rate limits are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters. The description still adds genuine value by spelling out the either/or relationship between 'manifest' and 'dependencies' and confirming the ecosystem default, which helps an agent pick the right input path.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Audit a whole dependency manifest') and scope ('for known vulnerabilities in one call'). The 'whole manifest' framing implicitly distinguishes it from sibling per-package tools like cve_lookup and package_vulnerabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the two input modes clearly ('paste a package.json as manifest, or pass a dependencies array'), which tells the agent how to invoke it in either situation. It stops short of explicitly naming alternatives (e.g., 'use package_vulnerabilities for a single package'), so usage is implied rather than fully routed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cve_lookupCVE LookupA

Read-onlyIdempotent

Inspect

Look up a CVE by ID and get a compact summary: description, CVSS score & severity, vector, CWE weakness, publish date, references — plus whether it is on the CISA Known-Exploited list (actively exploited in the wild) and its EPSS exploit-probability. Sources: NVD (NIST), CISA KEV, FIRST EPSS.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	Yes	CVE identifier, e.g. CVE-2021-44228 (case-insensitive; a bare 2021-44228 also works).

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	No
`cwe`	No
`cvss`	No
`status`	No
`sources`	No
`published`	No
`references`	No
`description`	No
`last_modified`	No
`known_exploited`	No
`exploit_probability`	No

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, open-world, non-destructive behavior. The description adds useful provenance (NVD/CISA/EPSS sources) and what each field means (KEV = actively exploited), but doesn't discuss rate limits, caching, or behavior when a CVE is unknown.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence front-loads the verb and enumerates outputs, then names sources. Every clause earns its place, though the output list is long enough to read as a run-on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with an output schema and full annotation coverage, the description supplies the provenance and output semantics an agent needs. Sibling routing is the only meaningful gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema itself documents the accepted format, including the case-insensitive and bare-number variants. The description adds no parameter detail but doesn't need to; baseline is 3, and the single well-documented parameter nudges it up slightly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (look up) and resource (CVE by ID) and enumerates the exact fields returned. An agent can distinguish this from siblings like epss_score or known_exploited, which are narrower single-source tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (single-CVE lookup) and lists sources, but never states when to prefer it over siblings such as known_exploited or epss_score for the same CVE. No exclusions or alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

epss_scoreEPSS ScoreA

Read-onlyIdempotent

Inspect

Get the EPSS exploit-probability score (0-1) and percentile for one or more CVEs — the likelihood each is exploited in the next 30 days. Use it to prioritize patching. Pass cve_id for one, or cve_ids (array or comma-separated) for many. Source: FIRST.org EPSS.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	No	A single CVE id.
`cve_ids`	No	Multiple CVE ids (or pass a comma-separated string).

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`as_of`	No
`model`	No
`scored`	No
`scores`	No
`source`	No

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's added value is provenance and semantics: the FIRST.org source, the 0-1 probability range, and the 30-day exploitation window. It omits freshness/caching behavior for EPSS data, which is the main remaining behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with the core purpose, then usage context, then parameter routing, then source. No sentence is wasted and the ordering matches how an agent would consume it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with a full output schema and rich annotations, the description covers purpose, source, and parameter routing adequately. Minor gaps remain around behavior when no parameter is supplied (required list is empty) and data freshness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description's 'Pass cve_id for one, or cve_ids (array or comma-separated) for many' mostly restates the schema's own parameter descriptions, adding only a light one-vs-many routing hint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource ('Get the EPSS exploit-probability score (0-1) and percentile for one or more CVEs') plus the metric's meaning and time horizon, which implicitly separates it from cve_lookup and known_exploited. It never names a sibling tool, so differentiation is achieved through the metric/source rather than explicit contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use it to prioritize patching' gives clear intended context for when the tool applies. It stops short of when-not guidance or naming the sibling tools (cve_lookup, known_exploited, package_vulnerabilities) that an agent should choose instead in other situations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

known_exploitedKnown ExploitedA

Read-onlyIdempotent

Inspect

Check whether a CVE is on the CISA Known Exploited Vulnerabilities (KEV) catalog — confirmed exploited in the wild — or list the most recently added exploited vulnerabilities. Pass cve_id to check one; omit it to list recent (optionally filter by vendor/product, or ransomware_only). Source: CISA KEV, updated ~daily.

ParametersJSON Schema

Name	Required	Description
`limit`	No	When listing, how many newest entries to return (default 20, max 100).
`cve_id`	No	Optional. Check a single CVE, e.g. CVE-2021-44228.
`vendor`	No	Optional. Filter by vendor or product name substring.
`ransomware_only`	No	Optional. Only vulns CISA links to known ransomware campaigns.

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	No
`cve_id`	No
`filter`	No
`listed`	No
`source`	No
`vendor`	No
`product`	No
`due_date`	No
`released`	No
`returned`	No
`date_added`	No
`catalog_count`	No
`catalog_version`	No
`required_action`	No
`vulnerabilities`	No
`known_ransomware_use`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds meaningful context beyond them: the data source (CISA KEV), its authority ('confirmed exploited in the wild'), and freshness ('updated ~daily'), which matters for judging staleness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences plus a short source note, with the check-vs-list branching front-loaded and no filler. Every clause carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and all four optional parameters are documented in the schema and reflected in the description. Both modes, filters, and data freshness are covered, leaving nothing an agent needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds mode semantics the schema does not convey — that omitting cve_id switches the tool into list mode and that vendor/product/ransomware_only are list-only filters. That is genuine value beyond the per-parameter text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('check whether a CVE is on the CISA KEV catalog') and names the dual listing mode, so the tool's function is unambiguous. It does not explicitly differentiate itself from siblings like cve_lookup or epss_score, relying on the named data source (CISA KEV) to do that implicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit mode-selection guidance: 'Pass cve_id to check one; omit it to list recent' and names the optional list filters. It stops short of stating when to prefer this over cve_lookup or epss_score, so no alternatives or exclusions are offered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

package_vulnerabilitiesPackage VulnerabilitiesB

Read-onlyIdempotent

Inspect

List known vulnerabilities for a software package (optionally a specific version) via OSV. Ecosystems: npm, pypi, cargo, go, maven, rubygems, nuget, composer, pub, hex.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Exact package name as published in that registry, e.g. lodash for npm, requests for pypi.
`version`	No	Optional; if given, only vulns affecting that version are returned
`ecosystem`	Yes	Package registry to look in. One of: npm, pypi, cargo, go, maven, rubygems, nuget, composer, pub, hex.

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	No
`source`	No
`version`	No
`ecosystem`	No
`vulnerabilities`	No
`vulnerability_count`	No

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — results come from OSV — but says nothing about coverage limits, rate limits, or freshness, and the return format is covered by the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the core action and data source front-loaded and the ecosystem enumeration last. No filler, no repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, rich annotations, and 100% schema coverage, the description is nearly complete for a lookup tool. The only real gap is routing guidance relative to the four sibling vulnerability tools, which the description does not address.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description's ecosystem list and 'optional version' note merely restate what the schema says, adding no new syntax, format, or constraint detail. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List known vulnerabilities for a software package') plus the data source (OSV) and an optional scope (specific version). An agent can tell it apart from cve_lookup or epss_score by the package-centric framing, though it never explicitly contrasts with those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the optional version parameter does, but gives no when-to-use guidance and no exclusions. With siblings like audit_dependencies (bulk scanning) and cve_lookup (lookup by CVE ID) present, an agent gets no explicit rule for choosing this tool over them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesOct 3, 2026

Changedaudit_dependencies2 fields changed

changedInput schema / properties / ecosystem / description

Previous value: -"Default npm"New value: +"Package registry for the dependencies: npm (default), pypi, cargo, go, maven, rubygems, nuget, composer, pub, or hex."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "ecosystem": {},
+    "findings": {},
+    "packages_audited": {},
+    "packages_not_found": {},
+    "packages_unverified": {},
+    "packages_with_vulnerabilities": {},
+    "source": {},
+    "total_vulnerabilities": {},
+    "verdict": {}
+  },
+  "type": "object"
+}

Changedcve_lookup2 fields changed

changedInput schema / properties / cve_id / description

Previous value: -"e.g. CVE-2021-44228"New value: +"CVE identifier, e.g. CVE-2021-44228 (case-insensitive; a bare 2021-44228 also works)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "cvss": {},
+    "cwe": {},
+    "description": {},
+    "exploit_probability": {},
+    "id": {},
+    "known_exploited": {},
+    "last_modified": {},
+    "published": {},
+    "references": {},
+    "sources": {},
+    "status": {}
+  },
+  "type": "object"
+}

Changedepss_score1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "as_of": {},
+    "model": {},
+    "note": {},
+    "scored": {},
+    "scores": {},
+    "source": {}
+  },
+  "type": "object"
+}

Changedknown_exploited1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "catalog_count": {},
+    "catalog_version": {},
+    "cve_id": {},
+    "date_added": {},
+    "due_date": {},
+    "filter": {},
+    "known_ransomware_use": {},
+    "listed": {},
+    "name": {},
+    "product": {},
+    "released": {},
+    "required_action": {},
+    "returned": {},
+    "source": {},
+    "vendor": {},
+    "vulnerabilities": {}
+  },
+  "type": "object"
+}

Changedpackage_vulnerabilities1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "ecosystem": {},
+    "name": {},
+    "source": {},
+    "version": {},
+    "vulnerabilities": {},
+    "vulnerability_count": {}
+  },
+  "type": "object"
+}

2 tool updatesSep 15, 2026
- Addedepss_score
- Addedknown_exploited
3 tool updatesSep 6, 2026
- First observedaudit_dependencies
- First observedcve_lookup
- First observedpackage_vulnerabilities

Related MCP Connectors

Security Intel MCP A
io.github.selflabbs
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Security Penetration Testing
2
dependency-trust A
ai.kaiv
Trust-check any dependency for agents: OpenSSF Scorecard, licenses, CVEs, deps. 7 ecosystems.
Security Developer Tools
51
vdb A
kr.ai.vdb
Check packages for CVEs, slopsquatting, and CISA KEV before your AI agent installs them.
Security Developer Tools Testing & QA Tools
71
AgentAegis A
io.github.astafford8488
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
Security Penetration Testing
2821

Related MCP Servers

DepHealth MCP
Security Code Analysis
hasarahman
A
license
A
quality
F
maintenance
Dependency security & health auditing for AI agents with no account or API key required.
Updated 3 months ago (2026-07-04 22:58 UTC)
2
2
MIT
vuln-intel-mcp
Security Penetration Testing
rohanrajnist
A
license
Not graded
quality
D
maintenance
Provides CVE lookup, search, and exploit intelligence from public vulnerability sources (NVD, CISA KEV, EPSS) for AI agents to produce remediation guidance without consuming LLM tokens for data fetching.
Updated 3 months ago (2026-07-06 06:18 UTC)
1
MIT
agentguard
Security Code Analysis AI & Machine Learning
shuaicongxiaomai
A
license
Not graded
quality
C
maintenance
Provides security checks for AI agents, including secret scanning, CVE lookup, and dependency vulnerability scanning, all running locally except for CVE lookups.
Updated 3 months ago (2026-07-02 10:56 UTC)
MIT
Fetter MCPofficial
Security Developer Tools CI/CD & DevOps
fetter-io
F
license
Not graded
quality
D
maintenance
Provides real-time Python package vulnerability data, enabling AI agents to check CVEs, CVSS scores, and safe versions for informed dependency decisions.
Updated 7 months ago (2026-02-26 22:38 UTC)
1
-