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 40 days
Last Tested: 2026-10-17 02:15
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-15 06:20 across 5 tools

Disambiguation4/5

cve_lookup partially overlaps with epss_score and known_exploited since it returns CVSS, KEV status, and EPSS data, but the bulk/batch-oriented and listing roles of the standalone tools keep them distinguishable. audit_dependencies vs package_vulnerabilities is also close (manifest vs single package), yet the input shapes are clearly different.

Naming Consistency4/5

All names use snake_case and are readable, though the pattern mixes verb_noun (audit_dependencies) with noun_verb/noun forms (cve_lookup, epss_score, known_exploited, package_vulnerabilities). Minor stylistic deviation but no chaos.

Tool Count5/5

Five tools is well-scoped for a vulnerability-intel server: one per data source/operation (NVD/CVE, EPSS, KEV, OSV, manifest audit). Each earns its place without redundancy bloat.

Completeness4/5

Covers the core lifecycle of vulnerability intel: manifest audit, per-package vuln listing, CVE detail, exploit-probability, and known-exploited status. Gaps remain for keyword/vendor CVE search or broader advisory feeds, but agents can work around via existing tools.

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
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`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 says nothing about what happens if neither manifest nor dependencies is supplied (required is empty) or whether both may be passed together.

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, front-loaded with purpose, then inputs, then return shape. No filler and nothing redundant to the point of waste.

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?

Covers purpose, both input modes, ecosystem default, and return shape, and an output schema exists so response details need not be spelled out. The one notable hole is the zero-required-parameter case: an agent cannot tell from the description whether omitting both inputs is valid or an error.

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 baseline is 3, but the description adds genuine semantics the schema does not: manifest and dependencies are alternative input modes expressed as an either/or, and the ecosystems list mirrors the schema's enum-less string. The mutual-exclusivity hint is real added value beyond the property descriptions.

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 (audit) and resource (whole dependency manifest) plus a differentiating scope: bulk audit of an entire manifest in one call, versus the per-package siblings like package_vulnerabilities and cve_lookup. An agent can tell this apart from single-package lookups without opening any schema.

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 clear input-selection context ('paste a manifest, or pass a dependencies array') and names the default ecosystem. It does not explicitly state when to prefer this over package_vulnerabilities, but the 'whole manifest in one call' framing strongly implies the bulk-vs-single distinction.

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
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`references`	No
`description`	No
`last_modified`	No
`known_exploited`	No
`exploit_probability`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is handled. The description adds real value beyond that by disclosing the aggregation sources (NVD/NIST, CISA KEV, FIRST EPSS), which tells the agent the data is a merged external snapshot. It does not mention rate limits, caching, or behavior for an unknown CVE ID.

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?

One dense sentence front-loads the purpose and enumerates the returned fields, followed by a short source-attribution sentence. No filler, no restatement of the title, and the highest-value information leads.

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?

An output schema exists, so return values need not be explained, yet the description usefully previews the payload shape. Combined with annotations covering safety, this is nearly complete; only error behavior for an unresolvable CVE ID is unaddressed.

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% and the schema already documents the accepted formats (CVE-2021-44228, case-insensitivity, bare 2021-44228). The description adds nothing further about the parameter, so the baseline 3 for fully-covered schema 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 (look up) and resource (CVE by ID) and enumerates the exact payload returned: CVSS, vector, CWE, dates, references, KEV status, EPSS. It implicitly differentiates from siblings known_exploited and epss_score by presenting itself as a single aggregate lookup, but never names those siblings explicitly.

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?

Usage is only implied — the required cve_id makes it obvious this is called when a CVE identifier is in hand. There is no guidance on when to prefer this aggregate lookup over the narrower known_exploited or epss_score siblings, and no exclusions or prerequisites stated.

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
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, openWorld, and non-destructive behavior, so the description only needs to add context. It does add meaningful context: the 0-1 scale, the 30-day forecast horizon, the FIRST.org source, and batch capability. It stops short of noting rate limits or error behavior for unknown CVE ids.

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 score definition and meaning before the invocation guidance and source attribution. No filler or repetition.

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 and full schema description coverage, the description need not document return values or parameters. It covers purpose, semantics, source, and parameter routing; the only omission is behavior when both parameters are supplied or when CVE ids are unrecognized, which is a minor 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%, so the baseline is 3. The description goes slightly beyond the schema by prescribing the routing rule: 'Pass cve_id for one, or cve_ids (array or comma-separated) for many,' which tells the agent which of the two optional parameters to choose in a given situation.

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 ('Get the EPSS exploit-probability score (0-1) and percentile for one or more CVEs') and explains what the number means via the 30-day exploitation window. It does not name a sibling for contrast, but the purpose is unmistakably distinct from cve_lookup, known_exploited, and the dependency 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?

'Use it to prioritize patching' gives an intended use case, so usage is implied rather than absent. However, there is no guidance on when to prefer this over known_exploited (confirmed exploitation) or cve_lookup, and no exclusions or prerequisites are stated.

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
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`catalog_count`	No
`catalog_version`	No
`required_action`	No
`vulnerabilities`	No
`known_ransomware_use`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the bar is lower; the description adds genuine value beyond them by naming the data provenance (CISA KEV) and freshness (~daily updates), which materially affects trust in the answer. It does not discuss rate limits, pagination of list mode, or staleness handling.

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: purpose and dual-mode invocation come first, filters second, provenance and freshness last. No filler, no restated boilerplate, and the most routing-relevant content is front-loaded.

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-shape explanation is unnecessary, and the description covers both operating modes, optional filters, data source, and update cadence. Nothing an agent needs to call this correctly is missing.

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 four parameters are already documented, and the description's restatement of the vendor/product and ransomware_only filters duplicates that. Its only marginal addition is scoping the filters to list mode, which is a small increment over the per-parameter schema text — baseline 3 applies.

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 dual verb+resource: checking a CVE against the CISA KEV catalog, or listing the most recently added exploited vulns. The scope ('confirmed exploited in the wild') cleanly separates it from the sibling cve_lookup (generic lookup) and epss_score (predicted likelihood), so an agent can route without opening any schema.

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?

Explicit mode-selection guidance: 'Pass cve_id to check one; omit it to list recent (optionally filter by vendor/product, or ransomware_only).' That removes all inference about how to invoke each mode, but it never states when to prefer this tool over the siblings for exploitability questions.

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

package_vulnerabilitiesPackage VulnerabilitiesA

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
`provenance`	No	Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.
`vulnerabilities`	No
`vulnerability_count`	No

TDQS

A3.5/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 structurally. The description adds one genuinely useful behavioral fact — the data comes from OSV, which tells the agent about provenance and coverage — but says nothing about breadth (direct vs transitive dependencies), result freshness, or rate limits.

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?

Two short sentences, front-loaded with the core action, with no filler. The trailing ecosystem list is slightly redundant with the schema's ecosystem description, which costs it a point but does let the agent scope the tool without opening the schema.

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, return values need no explanation, and annotations carry the safety profile, so the description only needs to establish scope and source — which it does. It is slightly thin on what happens when version is omitted (all versions?) and on dependency scope, but nothing blocks a correct invocation.

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%: name, version, and ecosystem are all documented in the schema, including the exact-name expectation and the version filter semantics. The description's ecosystem enumeration duplicates the schema's own list rather than adding syntax or edge-case detail, so the baseline 3 is appropriate.

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 optional version scope and the backing data source (OSV). It is clear on its own, but it never names or contrasts itself with the closest sibling, audit_dependencies, which is also package-oriented.

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?

Usage is only implied: the parenthetical 'optionally a specific version' hints at the version-scoping use case, but there is no when-to-use/when-not guidance and no routing between this, cve_lookup, epss_score, and audit_dependencies. An agent must infer the division of labor from tool names alone.

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 8, 2026

Changedaudit_dependencies1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedcve_lookup1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedepss_score1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedknown_exploited1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changedpackage_vulnerabilities1 field changed

addedOutput schema / properties / provenance

Added value: +{
+  "description": "Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at.",
+  "properties": {
+    "may_be_cached": {
+      "type": "boolean"
+    },
+    "publisher": {
+      "type": "string"
+    },
+    "served_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "upstream": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

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
OSV Dependency Vulnerability
Penetration Testing Testing & QA Tools Developer Tools
fairquery
A
license
A
quality
A
maintenance
Enables AI agents to submit npm, PyPI, Go, or Maven packages and manifests to the free OSV.dev database and receive per-package and per-advisory results with CVE mappings, CVSS scores, severities, and the versions that fix each issue. It also supports filtering by minimum severity, de-duplicating alias advisories, and machine-readable error/warning rows for CI gates and upgrade recommendations.
Updated a day ago (2026-10-16 23:42 UTC)
2
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 4 months ago (2026-07-02 10:56 UTC)
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources