Which integrations are available for this server?

Allows checking specific versions of NGINX for known CVEs and supply-chain risks. Allows checking JavaScript packages hosted on npm for vulnerabilities and supply-chain compromises. Allows checking specific versions of PostgreSQL for known CVEs and supply-chain risks. Allows checking Python packages hosted on PyPI for vulnerabilities and supply-chain compromises.

How do I use @attestd/mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@attestd/mcp Check if lodash 4.17.21 has any critical vulnerabilities." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@attestd/mcp

Official

by attestd-io

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

@attestd/mcp

npm version

Attestd checks whether a dependency version has exploitable CVEs or a confirmed supply-chain compromise. One API call returns a structured risk response.

Official Model Context Protocol (MCP) server for Attestd. Exposes CVE risk and supply-chain checks as tools for Claude Code, Claude Desktop, and any MCP-compatible client.

Get a free API key · Full docs

stdio transport: run via npx -y @attestd/mcp with no global install.
check_package_vulnerability: wraps GET /v1/check using @attestd/sdk.
check_batch_vulnerabilities: checks up to 100 packages in one call. Use for lockfile and manifest audits.
list_covered_products: returns Attestd-covered products. With an API key, returns live data from GET /v1/products. Without a key, returns the static bundled infrastructure list.
get_cve_details: returns CVSS, EPSS, KEV status, and affected products for a single CVE id.

Prerequisites

Node.js 18+
An Attestd API key from the portal. Required for check_package_vulnerability, check_batch_vulnerabilities, get_cve_details, and live list_covered_products.

Related MCP server: Cybersecurity MCP Server

Claude Code / MCP config

Add to ~/.claude/mcp.json or project .mcp.json:

{
  "mcpServers": {
    "attestd": {
      "command": "npx",
      "args": ["-y", "@attestd/mcp"],
      "env": {
        "ATTESTD_API_KEY": "your-api-key-here"
      }
    }
  }
}

Optional: override the API base URL (e.g. dev):

"env": {
  "ATTESTD_API_KEY": "your-api-key-here",
  "ATTESTD_BASE_URL": "https://dev.api.attestd.io"
}

Tools

`check_package_vulnerability`

Argument	Type	Description
`product`	string	Product slug (`nginx`, `postgresql`, `litellm`, …)
`version`	string	Exact version (`1.20.0`)

Returns JSON with:

Field	Meaning
`outsideCoverage`	`true` if the product is not covered. Unknown risk, not safe.
`riskState`	`critical` \| `high` \| `elevated` \| `low` \| `none` \| `null` when outside coverage
`activelyExploited`	CISA KEV signal
`remoteExploitable`	`true` if any matching CVE is remotely exploitable
`authenticationRequired`	`true` only when all matching CVEs require authentication
`patchAvailable` / `fixedVersion`	Patch guidance
`confidence`	Synthesis confidence 0.0–1.0
`cveIds`	CVE IDs contributing to the risk assessment
`typosquat`	Package name integrity: typosquat or AI-hallucinated name (`kind`, `resembles`, `likely_intended`)
`message`	Explanation when `outsideCoverage` is true
`supplyChainCompromised` / `supplyChainDescription`	PyPI/npm supply-chain signal

On invalid/missing API key or rate limit, returns isError: true with a JSON error string.

`check_batch_vulnerabilities`

Argument	Type	Description
`items`	array	Array of `{ product, version }` objects. Maximum 100 per call. Each item costs one API call.

Quota is checked upfront. If the batch would exceed your monthly quota, a 429 is returned before any calls are billed.

Returns JSON with count and results. Supported items include the same fields as check_package_vulnerability minus typosquat. Outside-coverage items return only product, version, outsideCoverage: true, and riskState: null.

`list_covered_products`

No arguments. With an API key, returns live JSON from GET /v1/products:

Field	Meaning
`source`	`"live"` when fetched from the API
`total`	Combined count of CVE products and supply chain packages
`cveProducts`	CVE infrastructure slugs with display names
`supplyChainPackages`	Monitored PyPI/npm packages

Without an API key, returns the static bundled list:

Field	Meaning
`source`	`"static"`
`count`	Number of bundled infrastructure products
`products`	Array of `{ slug, display }` entries

`get_cve_details`

Argument	Type	Description
`cve_id`	string	CVE identifier, e.g. `CVE-2021-44228`

Returns JSON with:

Field	Meaning
`found`	`true` when the CVE is in Attestd's database; `false` on 404 (not an error)
`cveId`	CVE identifier
`description`	NVD description text
`cvssScore` / `cvssVector`	CVSS base score and vector
`activelyExploited`	CISA KEV signal
`remoteExploitable`	Remotely exploitable
`authenticationRequired`	Authentication required for exploitation
`affectedProducts`	Attestd product slugs affected by this CVE
`epssScore` / `epssPercentile`	EPSS probability and percentile
`sourcePublishedAt` / `lastCheckedAt`	ISO timestamps

When the CVE is not found, returns { "found": false, "cveId": "..." } without isError. On invalid/missing API key or rate limit, returns isError: true with a JSON error string.

Verify locally

npm run build
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | node dist/index.js

License

MIT. See LICENSE.

Available Tools

4 tools

check_batch_vulnerabilitiesA

Read-onlyIdempotent

Check up to 100 software packages or infrastructure products in a single request. Each item is billed as one API call. Use this instead of multiple check_package_vulnerability calls when you need to audit a lockfile, manifest, or dependency list. Items outside Attestd coverage return outsideCoverage=true and should be treated as unknown risk, not safe. A 429 is returned before any results are delivered if the batch would exceed your monthly quota; no calls are billed in that case.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes	Products to check. Maximum 100 per call. Each item costs one API call.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of items returned.
`results`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

The description adds significant behavioral context beyond the annotations: each item is billed as one API call, items outside coverage return 'outsideCoverage=true' and are not safe, and quota exceedance returns a 429 before any results are delivered without billing. Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description does not contradict them.

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?

The description is a single paragraph with 4 clear sentences, each adding essential information. It begins with the core purpose, then details billing, usage context, and edge cases. While not split into sections, it is efficient and front-loaded. Slightly verbose for a very concise tool, but still well-structured.

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?

Given the presence of an output schema (not shown but mentioned), 100% schema coverage, and rich annotations, the description covers all critical aspects: purpose, usage distinction, billing model, coverage edge case, and quota handling. No gaps remain for an agent to understand invocation and result interpretation.

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% (all required and optional properties described with descriptions). The description reinforces the maximum of 100 items and the cost per item, and adds billing nuance and coverage behavior. This goes beyond the schema definitions, earning a score above the baseline of 3.

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?

The description clearly states that this tool checks vulnerabilities for up to 100 software packages or infrastructure products in a single request, using specific verbs ('check') and resource ('batch vulnerabilities'). It distinguishes itself from the sibling tool 'check_package_vulnerability' by targeting batch scenarios.

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?

The description explicitly states when to use this tool ('instead of multiple check_package_vulnerability calls when you need to audit a lockfile, manifest, or dependency list') and provides guidance on handling items outside coverage ('treated as unknown risk, not safe') and quota limits ('429 returned before any results... no calls billed'). It does not explicitly mention when not to use it (e.g., single item), but the context implies it.

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

check_package_vulnerabilityA

Read-onlyIdempotent

Check whether a software package or infrastructure product version has known CVE vulnerabilities or a confirmed supply chain compromise. Call this before adding, updating, or recommending any npm, PyPI, or infrastructure dependency, including mid-conversation when a developer asks about installing or upgrading a package. outsideCoverage=true means Attestd has no data for that product; treat as unknown risk, not safe. Covers infrastructure products (nginx, PostgreSQL, Redis, Docker, Kubernetes, etc.) and PyPI/npm packages.

ParametersJSON Schema

Name	Required	Description	Default
`product`	Yes	Package or product slug, e.g. "nginx", "runc", "@bitwarden/cli", "litellm"
`version`	Yes	Exact version string, e.g. "1.20.0"

Output Schema

ParametersJSON Schema

Name	Required	Description
`error`	No	Error message when the tool returns isError.
`cveIds`	No	CVE IDs contributing to the risk assessment.
`maxEpss`	No	Highest EPSS probability across matching CVEs. Omitted or null when unavailable.
`message`	No	Explanation when outsideCoverage is true.
`riskState`	No	Risk band: "critical", "high", "elevated", "low", "none", or null when outside coverage.
`typosquat`	No	Package name integrity signal when the name is a typosquat or AI-hallucinated package.
`confidence`	No	Synthesis confidence from 0.0 to 1.0.
`riskFactors`	No	Risk factor vocabulary driving riskState.
`fixedVersion`	No	Earliest clean version to recommend. Omitted or null when unknown.
`patchAvailable`	No	True when a fixed version with no critical/high CVEs is known.
`outsideCoverage`	No	True when Attestd has no CVE data for this product. Unknown risk, not safe.
`activelyExploited`	No	True when the version appears in the CISA KEV catalog.
`remoteExploitable`	No	True when any matching CVE is remotely exploitable.
`authenticationRequired`	No	True only when all matching CVEs require authentication.
`supplyChainCompromised`	No	True when a malicious PyPI or npm publish was detected.
`supplyChainDescription`	No	Human-readable supply-chain event description when present.

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already indicate the tool is read-only, idempotent, open-world, and non-destructive. The description adds valuable context by explaining that outsideCoverage=true means no data and should be treated as unknown risk, not safe. It also clarifies the scope of coverage (infrastructure products and PyPI/npm packages), going beyond what annotations provide.

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?

The description is a single paragraph that efficiently conveys purpose, usage, and important behavioral notes. It is front-loaded with the core action and includes contextual guidance without unnecessary verbosity. Slightly more structure (e.g., bullet points) could improve readability, but it is concise overall.

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?

Given the presence of an output schema (not shown), return values are likely documented there. The description covers the tool's purpose, when to use it, coverage scope, and interpretation of a key response field (outsideCoverage). It implicitly differentiates from siblings by being a single-check tool, but explicit differentiation would improve completeness.

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?

The input schema has 100% coverage with descriptions for both parameters. The description adds minimal extra meaning beyond examples in the schema; it mentions 'package or product slug' and 'exact version string', which are already present. Baseline 3 is appropriate.

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?

The description clearly states the tool checks for known CVEs and supply chain compromises, specifies the verb 'check', and identifies the resource as package or infrastructure product vulnerability. It explicitly mentions when to call it (before adding/updating dependencies), which distinguishes it from siblings like list_covered_products or get_cve_details.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: 'Call this before adding, updating, or recommending any npm, PyPI, or infrastructure dependency, including mid-conversation when a developer asks about installing or upgrading a package.' It also explains the meaning of outsideCoverage=true, helping the agent interpret results correctly.

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

get_cve_detailsA

Read-onlyIdempotent

Return full details for a single CVE id (CVSS, EPSS, KEV status, affected products). Use when you need context on a specific CVE before recommending a patch or explaining risk to a developer.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	Yes	CVE identifier, e.g. "CVE-2021-44228"

Output Schema

ParametersJSON Schema

Name	Required	Description
`cveId`	No
`error`	No
`found`	No	False when the CVE id is not in Attestd's database.
`cvssScore`	No
`epssScore`	No
`cvssVector`	No
`description`	No
`lastCheckedAt`	No
`epssPercentile`	No
`affectedProducts`	No
`activelyExploited`	No
`remoteExploitable`	No
`sourcePublishedAt`	No
`authenticationRequired`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds value by specifying the return details (CVSS, EPSS, KEV, affected products), providing extra context beyond the annotations.

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 sentences, front-loaded with purpose and usage guidance. No wasted words.

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 a single parameter, full schema coverage, an output schema present, and enough context in the description to explain what is returned, the description is complete for a simple lookup tool.

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?

The schema already fully describes the single parameter (cve_id) with 100% coverage and an example. The description adds minimal extra meaning beyond restating 'single CVE id', so baseline 3 is appropriate.

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?

The description clearly states the tool returns full details for a single CVE id, listing specific data fields (CVSS, EPSS, KEV status, affected products). It is distinct from sibling tools like check_package_vulnerability, which focus on packages or batches.

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?

The description explicitly states when to use the tool: 'Use when you need context on a specific CVE before recommending a patch or explaining risk.' It does not mention alternatives or exclusions, but the usage context is clear.

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

list_covered_productsA

Read-onlyIdempotent

Returns Attestd-covered products for CVE checks. With an API key, returns live data from GET /v1/products (CVE infrastructure slugs plus monitored supply chain packages). Without a key, returns the static bundled infrastructure list. PyPI and npm packages also work with check_package_vulnerability even when absent from this list.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	No	Number of covered infrastructure products (static source only).
`total`	No	Total covered CVE products plus supply chain packages (live source only).
`source`	No	static when no API key is provided; live when fetched from GET /v1/products.
`products`	No	Covered CVE infrastructure products (static source only).
`cveProducts`	No	CVE infrastructure products from GET /v1/products (live source only).
`supplyChainPackages`	No	Monitored PyPI and npm packages from GET /v1/products (live source only).

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations (readOnly, openWorld, idempotent), the description adds behavioral context: it returns live vs. static data based on API key availability. No contradictions with annotations.

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 sentences, front-loaded with main purpose, every sentence adds unique value with no redundancy.

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?

Given zero parameters, rich annotations, and an output schema existing, the description fully covers behavior variations and links to sibling tools for edge cases.

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?

The input schema has zero parameters, so the description cannot add parameter meaning. Baseline 4 is appropriate as the description provides behavioral context (API key effect) that compensates for lack of parameters.

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?

The description clearly states it returns Attested-covered products for CVE checks, distinguishing between live data with an API key and a static list without. It also differentiates from sibling tools like check_package_vulnerability by noting that PyPI and npm packages work with that tool even if absent from this list.

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

Usage Guidelines5/5

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

Explicitly explains when to use this tool (for CVE checks) and provides alternatives for checking packages not in the list via check_package_vulnerability. Also specifies behavior differences with and without an API key.

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.

4 tool updatesv0.3.0Jul 28, 2026
- First observedcheck_batch_vulnerabilities
- First observedcheck_package_vulnerability
- First observedget_cve_details
- First observedlist_covered_products

Deploy Server

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

TDQS

A4.6/5.0

Scored 2026-07-28 21:35 across 4 tools

Disambiguation5/5

Each tool targets a distinct operation: single package check, batch check, product listing, and CVE details. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, e.g., check_package_vulnerability, list_covered_products.

Tool Count5/5

Four tools cover the essential needs for vulnerability checking: individual, batch, reference data, and details. Well-scoped without redundancy.

Completeness4/5

Core workflows are covered (check, batch, list, details). Minor gap: no tool to manage coverage subscriptions or alerts, but not critical for the tool's purpose.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

sectora A
io.github.megabrainee
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
Security Monitoring AI & Machine Learning
142
Security Intel MCP A
com.datakoot
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Penetration Testing Security
31
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
NPMScan A
io.github.salemalem
Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups
Security Code Analysis Developer Tools
231

Related MCP Servers

CVE Checker for Node Modules
Developer Tools Security Testing & QA Tools
RobinBreugelmans-S
F
license
B
quality
D
maintenance
Enables checking npm packages for known security vulnerabilities using the OSV API before installation. Supports both single package checks and bulk vulnerability scanning for multiple packages at once.
Updated a year ago (2025-10-24 13:45 UTC)
2
-
Cybersecurity MCP Server
Security Penetration Testing
AiAgentKarl
A
license
Not graded
quality
D
maintenance
Enables searching the NIST NVD for CVEs, retrieving full CVE details, checking software for known vulnerabilities, and searching the CPE database.
Updated 5 months ago (2026-04-03 16:05 UTC)
MIT
kr.ai.vdb/vdb
0pstech
A
license
Not graded
quality
B
maintenance
MCP server for checking packages against an AI-aware vulnerability database, including CVEs, slopsquatting, CISA KEV, and MCP-server trust profiles.
Updated 2 days ago (2026-09-13 02:11 UTC)
Elastic 2.0
nist-nvd-mcp-server
Security Government Data Research & Data
cyanheads
A
license
Not graded
quality
A
maintenance
Search and audit CVEs by keyword, severity, CWE, CISA KEV status, and CPE via the NIST National Vulnerability Database.
Updated 21 days ago (2026-08-25 05:56 UTC)
139 npm
1
Apache 2.0