How do I use NIST NVD MCP Server?

1. Click on "Install 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., "@NIST NVD MCP Server Search for critical CVEs with CISA KEV in the last 30 days" 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.

NIST NVD MCP Server

by Cyreslab-AI

Overview Schema Related Servers Score Discussions

JavaScript

Remote

NIST NVD MCP Server

A comprehensive Model Context Protocol (MCP) server providing access to the NIST National Vulnerability Database (NVD) API. This server enables AI agents to search, retrieve, and analyze vulnerability data from the authoritative U.S. government repository of standards-based vulnerability management data.

Features

Core Capabilities

CVE Search & Retrieval: Advanced search with keyword, date, severity, and CWE filtering
CPE-Based Searches: Find vulnerabilities affecting specific products and versions
CVSS Analysis: Filter by CVSS v2/v3/v4 scores and severity ratings
Change History Tracking: Monitor CVE modifications and analysis updates
High-Priority Detection: Automated discovery of CISA KEV, CERT alerts, and critical CVEs
Comprehensive Filtering: Date ranges, rejection status, source identifiers, and more

Advanced Features

Intelligent Caching: 5-minute TTL with automatic cleanup
Rate Limiting: Built-in retry logic with exponential backoff
Error Handling: Comprehensive HTTP error handling and user-friendly messages
Data Validation: NIST API compliance with proper date range enforcement (120-day max)
Rich Formatting: Enhanced JSON responses with security metrics extraction

Related MCP server: MCP NVD Server

Installation

npm install @cyreslab/nist-nvd-mcp-server

Or clone and build locally:

git clone https://github.com/cyreslab/nist-nvd-mcp-server.git
cd nist-nvd-mcp-server
npm install
npm run build

Quick Start

Basic Usage

# Run the server
npm start

# Or run in development mode
npm run dev

Integration with AI Agents

Add to your MCP client configuration:

{
  "servers": {
    "nist-nvd": {
      "command": "node",
      "args": ["/path/to/nist-nvd-mcp-server/build/index.js"]
    }
  }
}

Available Tools

1. search_cves

Search CVEs with comprehensive filtering options.

Parameters:

keywordSearch (string): Search terms in CVE descriptions
keywordExactMatch (boolean): Exact phrase matching
cvssV3Severity (enum): LOW, MEDIUM, HIGH, CRITICAL
cvssV2Severity (enum): LOW, MEDIUM, HIGH
cweId (string): Common Weakness Enumeration ID (e.g., "CWE-79")
hasKev (boolean): CISA Known Exploited Vulnerabilities only
hasCertAlerts (boolean): US-CERT Technical Alerts only
hasCertNotes (boolean): CERT/CC Vulnerability Notes only
noRejected (boolean): Exclude rejected CVEs
pubStartDate/pubEndDate (string): Publication date range (ISO-8601)
lastModStartDate/lastModEndDate (string): Modification date range
resultsPerPage (number): 1-2000, default 20
startIndex (number): Pagination offset

Example:

{
  "keywordSearch": "remote code execution",
  "cvssV3Severity": "CRITICAL",
  "hasKev": true,
  "resultsPerPage": 10
}

2. get_cve

Retrieve detailed information about a specific CVE.

Parameters:

cveId (string, required): CVE identifier (e.g., "CVE-2021-44228")

Example:

{
  "cveId": "CVE-2021-44228"
}

3. search_cves_by_cpe

Find CVEs affecting specific products using CPE.

Parameters:

cpeName (string): Full CPE name
virtualMatchString (string): CPE match string for broader searches
isVulnerable (boolean): Only return vulnerable configurations
versionStart/versionEnd (string): Version range filtering
versionStartType/versionEndType (enum): "including" or "excluding"

Example:

{
  "virtualMatchString": "cpe:2.3:a:apache:log4j",
  "versionStart": "2.0",
  "versionStartType": "including",
  "versionEnd": "2.15.0",
  "versionEndType": "excluding"
}

4. search_cves_by_cvss

Search CVEs by CVSS vector strings and severity.

Parameters:

cvssV3Metrics (string): CVSSv3 vector string
cvssV3Severity (enum): LOW, MEDIUM, HIGH, CRITICAL
cvssV2Metrics (string): CVSSv2 vector string
cvssV2Severity (enum): LOW, MEDIUM, HIGH
cvssV4Metrics (string): CVSSv4 vector string (experimental)

Example:

{
  "cvssV3Severity": "CRITICAL"
}

5. search_recent_cves

Get recently published CVEs.

Parameters:

days (number): Days back from today (1-120)
pubStartDate/pubEndDate (string): Custom date range
resultsPerPage (number): Default 50

Example:

{
  "days": 7,
  "resultsPerPage": 25
}

6. search_modified_cves

Get recently modified CVEs.

Parameters:

days (number): Days back from today (1-120)
lastModStartDate/lastModEndDate (string): Custom date range

Example:

{
  "days": 3
}

7. get_cve_change_history

Track CVE modification history.

Parameters:

cveId (string): Specific CVE to track
changeStartDate/changeEndDate (string): Date range for changes
eventName (enum): Filter by event type:
- "CVE Received", "Initial Analysis", "Reanalysis"
- "CVE Modified", "Modified Analysis", "CVE Translated"
- "Vendor Comment", "CVE Source Update"
- "CPE Deprecation Remap", "CWE Remap"
- "Reference Tag Update", "CVE Rejected"
- "CVE Unrejected", "CVE CISA KEV Update"

Example:

{
  "cveId": "CVE-2021-44228",
  "eventName": "Initial Analysis"
}

8. search_high_priority_cves

Find high-priority CVEs using multiple risk indicators.

Parameters:

includeKev (boolean): Include CISA KEV (default: true)
includeCertAlerts (boolean): Include CERT alerts (default: true)
includeCriticalCvss (boolean): Include critical CVSS (default: true)
minCvssScore (number): Minimum CVSS threshold (0-10, default: 7.0)
keywordSearch (string): Additional keyword filter
days (number): Limit to recent CVEs (max 120)

Example:

{
  "minCvssScore": 9.0,
  "days": 30,
  "keywordSearch": "authentication bypass"
}

Response Format

All tools return structured JSON responses with:

CVE Responses

{
  "summary": {
    "search_context": "search description",
    "total_results": 1500,
    "showing_results": 20,
    "results_per_page": 20,
    "start_index": 0,
    "timestamp": "2025-06-08T14:26:00.000Z"
  },
  "vulnerabilities": [
    {
      "cve_id": "CVE-2021-44228",
      "status": "Analyzed",
      "published": "2021-12-10T10:15:09.043",
      "last_modified": "2021-12-29T00:15:09.427",
      "description": "Apache Log4j2 <=2.14.1 JNDI features...",
      "cvss": {
        "v3_score": 10.0,
        "v3_severity": "CRITICAL",
        "v2_score": 9.3
      },
      "weaknesses": ["CWE-502", "CWE-400"],
      "reference_count": 15,
      "cisa_kev": {
        "exploitAdd": "2021-12-10",
        "actionDue": "2021-12-24",
        "requiredAction": "Apply updates per vendor instructions.",
        "vulnerabilityName": "Apache Log4j2 Remote Code Execution Vulnerability"
      },
      "configurations_count": 200
    }
  ],
  "raw_response_metadata": {
    "format": "NVD_CVE",
    "version": "2.0",
    "has_more_results": true
  }
}

Change History Responses

{
  "summary": {
    "search_context": "change history for CVE-2021-44228",
    "total_changes": 5,
    "showing_changes": 5
  },
  "changes": [
    {
      "cve_id": "CVE-2021-44228",
      "event_name": "Initial Analysis",
      "change_id": "ABC123-DEF456",
      "source": "nvd@nist.gov",
      "created": "2021-12-10T15:30:00.000Z",
      "details_count": 8,
      "sample_details": [
        {
          "action": "Added",
          "type": "CVSS V3.1",
          "newValue": "NIST AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
        }
      ]
    }
  ]
}

Use Cases for AI Agents

1. Threat Intelligence Analysis

{
  "tool": "search_high_priority_cves",
  "args": {
    "days": 7,
    "minCvssScore": 8.0,
    "includeKev": true
  }
}

2. Software Asset Vulnerability Assessment

{
  "tool": "search_cves_by_cpe",
  "args": {
    "virtualMatchString": "cpe:2.3:a:microsoft:windows",
    "versionStart": "10",
    "versionStartType": "including"
  }
}

3. Security Research & Analysis

{
  "tool": "search_cves",
  "args": {
    "keywordSearch": "authentication bypass",
    "cvssV3Severity": "HIGH",
    "noRejected": true
  }
}

4. Vulnerability Lifecycle Monitoring

{
  "tool": "get_cve_change_history",
  "args": {
    "changeStartDate": "2024-01-01T00:00:00.000Z",
    "changeEndDate": "2024-01-31T23:59:59.999Z",
    "eventName": "CISA KEV Update"
  }
}

API Limits & Best Practices

NIST NVD API Constraints

Date Range Limit: Maximum 120 consecutive days
Rate Limiting: Built-in retry logic handles API limits
No API Key Required: Free access to public data
Data Freshness: Real-time access to official NIST data

Optimization Tips

Use caching effectively (5-minute TTL implemented)
Implement reasonable page sizes (20-100 results)
Leverage specific filters to reduce result sets
Monitor for rate limiting in high-volume scenarios

Error Handling

The server provides comprehensive error handling:

404: Resource not found
400: Invalid request parameters
429: Rate limit exceeded (automatic retry)
Timeout: Request timeout with retry logic
Validation: Parameter validation with helpful messages

Technical Details

Architecture

TypeScript: Full type safety and modern ES2022
MCP SDK: Official Model Context Protocol implementation
Axios: HTTP client with retry logic and timeouts
Caching: In-memory cache with TTL and cleanup
Error Recovery: Exponential backoff and circuit breaker patterns

Performance Features

Smart Caching: Reduces API calls and improves response times
Pagination: Efficient handling of large result sets
Parallel Requests: High-priority search combines multiple API calls
Memory Management: Automatic cache cleanup and optimization

Contributing

Fork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Submit a pull request

License

MIT License - see LICENSE file for details

Support

Issues: GitHub Issues
Documentation: API Documentation
Community: MCP Community

Version History

v1.0.0

Initial release with full NIST NVD API 2.0 support
8 comprehensive tools for vulnerability research
Advanced filtering and search capabilities
Change history tracking
High-priority CVE detection
Production-ready caching and error handling

Available Tools

8 tools

get_cveA

Get detailed information about a specific CVE by its ID

ParametersJSON Schema

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

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only says 'Get detailed information' without disclosing read-only nature, return format, or potential side effects.

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?

Single sentence, front-loaded, no unnecessary words.

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

Completeness3/5

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

Minimal description for a simple tool, but lacks details about what 'detailed information' includes, especially without output schema.

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 coverage is 100% and already describes the parameter with pattern and example. Description adds no extra meaning beyond the schema.

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?

Description clearly states it gets detailed information about a specific CVE by ID, distinguishing it from sibling search tools.

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?

Implies use when you have a specific CVE ID, but does not explicitly exclude alternatives or mention when not to use.

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

get_cve_change_historyA

Get change history for a specific CVE or all changes within a date range

ParametersJSON Schema

Name	Required	Description
`cveId`	No	CVE identifier to get change history for
`eventName`	No	Filter by specific type of change event
`changeEndDate`	No	End date for change range (ISO-8601 format, required if changeStartDate used)
`resultsPerPage`	No	Number of results per page (1-5000, default: 100)
`changeStartDate`	No	Start date for change range (ISO-8601 format, max 120 day range)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as whether it is read-only, authentication requirements, or rate limits. It simply states the purpose without behavioral context.

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?

The description is a single, clear sentence that front-loads the core purpose with no extraneous information.

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

Completeness3/5

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

With 5 optional parameters and no output schema, the description is somewhat incomplete. It does not explain return format, pagination behavior, or date format expectations, though the schema partially compensates.

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 schema already explains all parameters. The main description adds no additional meaning beyond what the schema provides, resulting in a baseline score.

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 gets change history for a specific CVE or all changes within a date range, distinguishing it from sibling tools like get_cve or search_cves which focus on CVE data retrieval.

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 for historical changes but lacks explicit guidance on when to use this tool versus alternatives, such as when a date range is needed or when to use search_cves instead.

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

search_cvesC

Search CVEs with comprehensive filtering options including keywords, CVSS scores, dates, and more

ParametersJSON Schema

Name	Required	Description
`cweId`	No	Filter by Common Weakness Enumeration ID (e.g., "CWE-79", "CWE-89")
`hasKev`	No	If true, only return CVEs in CISA's Known Exploited Vulnerabilities catalog
`noRejected`	No	If true, exclude rejected CVEs from results
`pubEndDate`	No	End date for publication range (ISO-8601 format, required if pubStartDate used)
`startIndex`	No	Starting index for pagination (0-based)
`hasCertNotes`	No	If true, only return CVEs with CERT/CC Vulnerability Notes
`pubStartDate`	No	Start date for publication range (ISO-8601 format, max 120 day range)
`hasCertAlerts`	No	If true, only return CVEs with US-CERT Technical Alerts
`keywordSearch`	No	Search for keywords in CVE descriptions (e.g., "Microsoft", "remote code execution")
`cvssV2Severity`	No	Filter by CVSSv2 severity rating
`cvssV3Severity`	No	Filter by CVSSv3 severity rating
`lastModEndDate`	No	End date for last modification range (ISO-8601 format, required if lastModStartDate used)
`resultsPerPage`	No	Number of results per page (1-2000, default: 20)
`lastModStartDate`	No	Start date for last modification range (ISO-8601 format, max 120 day range)
`keywordExactMatch`	No	If true, search for exact phrase match (requires keywordSearch)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It omits crucial details such as whether the operation is read-only, any rate limits, or pagination behavior beyond what the schema provides. The single sentence does not cover these aspects.

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 sentence, which is concise. It front-loads the action and resource, then lists example filters. However, it could be more structured, and the word 'comprehensive' adds little value.

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

Completeness2/5

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

The tool has 15 parameters and no output schema or annotations. The description fails to provide context on return values, pagination limits, or how parameters interact (e.g., date ranges). For a complex search tool, this is inadequate for complete understanding.

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 adds no new semantic meaning beyond the parameter descriptions already present in the schema. It does not elaborate on parameter usage or constraints.

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 clearly states the action ('Search') and resource ('CVEs') with an overview of filtering options. However, it does not explicitly distinguish from sibling tools with similar purposes like search_cves_by_cpe, leaving some ambiguity about when to use this generic search.

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?

No guidance is provided on when to use this tool versus its siblings (e.g., search_cves_by_cvss or search_recent_cves). The description lacks any 'when-to-use' or 'when-not-to-use' information, making it harder for an AI agent to select the correct tool.

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

search_cves_by_cpeB

Find CVEs affecting specific products using Common Platform Enumeration (CPE)

ParametersJSON Schema

Name	Required	Description
`cpeName`	No	CPE name (e.g., "cpe:2.3:a:apache:log4j:2.14.1:::::::*")
`versionEnd`	No	Ending version for range search (requires virtualMatchString)
`isVulnerable`	No	If true with cpeName, only return CVEs where the CPE is vulnerable
`versionStart`	No	Starting version for range search (requires virtualMatchString)
`resultsPerPage`	No	Number of results per page (1-2000, default: 20)
`versionEndType`	No	Whether versionEnd is inclusive or exclusive
`versionStartType`	No	Whether versionStart is inclusive or exclusive
`virtualMatchString`	No	CPE match string for broader searches (e.g., "cpe:2.3:a:apache:*")

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided. The description only states the tool's purpose, with no disclosure of behavioral traits such as rate limits, authentication needs, or side effects.

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?

One sentence, 13 words – highly concise. Purpose is front-loaded. However, no structured sections for parameters or usage.

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

Completeness2/5

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

Given 8 parameters, no output schema, and no annotations, the description is too brief. It lacks details on response format, version range logic, and optional parameter interactions.

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 covers 100% of parameters with descriptions. The tool description does not add new semantic meaning beyond what the schema already provides.

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?

Description clearly states the tool finds CVEs using CPE, a specific search method. It distinguishes from siblings like search_cves_by_cvss and search_cves by the use of CPE.

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?

No explicit guidance on when to use vs alternatives. The description implies CPE-based search, but lacks when-not or alternative suggestions.

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

search_cves_by_cvssC

Search CVEs by CVSS vector strings and severity ratings

ParametersJSON Schema

Name	Required	Description
`cvssV2Metrics`	No	CVSSv2 vector string (e.g., "AV:N/AC:L/Au:N/C:C/I:C/A:C")
`cvssV3Metrics`	No	CVSSv3 vector string (e.g., "AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H")
`cvssV4Metrics`	No	CVSSv4 vector string (experimental)
`cvssV2Severity`	No	CVSSv2 severity rating
`cvssV3Severity`	No	CVSSv3 severity rating
`cvssV4Severity`	No	CVSSv4 severity rating
`resultsPerPage`	No	Number of results per page (1-2000, default: 20)

TDQS

C2.9/5.0

Behavior2/5

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

The description lacks behavioral details beyond the basic search function. With no annotations, it fails to disclose important traits such as whether results are paginated (though the schema includes resultsPerPage), how multiple parameters interact (AND/OR), or any authentication requirements.

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 sentence, front-loading the core purpose. It is efficient but could benefit from additional context without becoming verbose.

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

Completeness2/5

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

Given the 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain how parameters combine, what the output returns, or how it differs from sibling tools beyond the CVSS focus.

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 all 7 parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate as the schema already provides sufficient parameter semantics.

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 states 'Search CVEs by CVSS vector strings and severity ratings', clearly indicating the resource (CVEs) and method (CVSS-based search). It distinguishes from siblings like search_cves (generic) and search_cves_by_cpe (by CPE), though it doesn't explicitly contrast with other CVSS-related tools.

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?

No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives from the sibling list (e.g., use search_cves for general keyword search) or specify when this tool should be preferred over others.

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

search_high_priority_cvesB

Search for high-priority CVEs using multiple risk indicators

ParametersJSON Schema

Name	Required	Description
`days`	No	Look for high-priority CVEs from the last N days (max 120)
`includeKev`	No	Include CISA Known Exploited Vulnerabilities (default: true)
`minCvssScore`	No	Minimum CVSS score threshold (0-10, default: 7.0)
`keywordSearch`	No	Additional keyword filter for high-priority search
`resultsPerPage`	No	Number of results per page (1-2000, default: 50)
`includeCertAlerts`	No	Include CVEs with US-CERT Technical Alerts (default: true)
`includeCriticalCvss`	No	Include CVEs with CRITICAL CVSSv3 severity (default: true)

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It mentions 'multiple risk indicators' but does not disclose how they interact, default behaviors, pagination, or any side effects. Insufficient for a 7-parameter tool.

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?

Single sentence, front-loaded with verb and resource, no fluff. Efficiently communicates purpose.

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

Completeness2/5

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

Despite 7 parameters and no output schema, the description is minimal. It does not explain how filters combine, default values, or result format, leaving gaps for a tool of this complexity.

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 coverage is 100%, so the input schema documents all parameters fully. The description adds no additional meaning beyond the schema, meeting baseline but not adding value.

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's action ('Search for') and resource ('high-priority CVEs'), and distinguishes it from siblings by focusing on high-priority and multiple risk indicators.

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 this tool is for high-priority CVEs but does not explicitly state when to use it over alternatives like search_cves or search_cves_by_cvss. No when-not-to-use guidance.

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

search_modified_cvesB

Get CVEs that were recently modified within a specified date range

ParametersJSON Schema

Name	Required	Description
`days`	No	Number of days back from today (alternative to date range, max 120)
`lastModEndDate`	No	End date for modification range (ISO-8601 format)
`resultsPerPage`	No	Number of results per page (1-2000, default: 50)
`lastModStartDate`	No	Start date for modification range (ISO-8601 format)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions only the purpose and scope, lacking details on pagination, rate limits, or what happens with empty results. The schema hints at pagination via resultsPerPage but description does not elaborate.

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?

One sentence of 10 words is very concise. While it could include a bit more context without becoming verbose, it is efficient and front-loaded.

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

Completeness2/5

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

This tool has no annotations and no output schema. The description is minimal and does not cover expected return values, pagination behavior, or error scenarios. Given the parameter count and complexity, more detail is needed.

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?

Input schema has 100% coverage with descriptions for all 4 parameters. The tool description does not add any extra semantic meaning beyond what the schema already provides.

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 clearly states the verb 'Get', resource 'CVEs', and scope 'recently modified within a specified date range'. However, it does not differentiate from sibling tools like search_recent_cves, which may also involve recent CVEs.

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 for fetching modified CVEs by date range but offers no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.

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

search_recent_cvesB

Get recently published CVEs within a specified date range

ParametersJSON Schema

Name	Required	Description
`days`	No	Number of days back from today (alternative to date range, max 120)
`pubEndDate`	No	End date for publication range (ISO-8601 format)
`pubStartDate`	No	Start date for publication range (ISO-8601 format)
`resultsPerPage`	No	Number of results per page (1-2000, default: 50)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It states it 'Get recently published CVEs', which implies a read operation, but fails to mention pagination, ordering, or what constitutes 'recent' given the parameters. Lacks important details for safe invocation.

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?

The description is a single, front-loaded sentence that communicates the core purpose without extraneous words. Highly concise and efficient, earning top score.

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

Completeness3/5

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

Given the tool has 4 optional parameters, no output schema, and no annotations, the description is somewhat minimal. It conveys the basic purpose but does not elaborate on behavior like pagination, result format, or edge cases. Adequate but not complete.

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 description coverage is 100%, so the tool description does not need to add extra parameter meaning. However, it adds no additional context beyond the schema's descriptions. 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?

The description clearly indicates the tool retrieves recently published CVEs within a date range, using a specific verb ('Get') and resource ('recently published CVEs'). While it hints at a specific scope, it does not explicitly differentiate from sibling tools like 'search_cves' which also handle date ranges, but it is still clear enough.

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 provides no guidance on when to use this tool versus alternatives (e.g., 'search_cves' for general searches). It does not specify prerequisites, exclusions, or context that would help an agent decide between siblings. Usage is only implied.

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. Dates show when Glama detected each change.

8 tool updatesv1.0.0Jul 13, 2026
- First observedget_cve
- First observedget_cve_change_history
- First observedsearch_cves
- First observedsearch_cves_by_cpe
- First observedsearch_cves_by_cvss
- First observedsearch_high_priority_cves
- First observedsearch_modified_cves
- First observedsearch_recent_cves

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct search or retrieval operation: specific CVE by ID, change history, comprehensive search, CPE-based, CVSS-based, high-priority, modified, or recent. No overlap in functionality.

Naming Consistency5/5

All tool names begin with 'get' or 'search', followed by a descriptive noun phrase in snake_case. The pattern is uniform across all 8 tools.

Tool Count5/5

8 tools is an appropriate scope for a CVE database server, providing essential retrieval operations without being too few or excessive.

Completeness5/5

The server covers all typical read operations for CVE data: single lookup, history, and multiple search dimensions (keywords, CPE, CVSS, priority, modification date, publication date). No gaps for its read-only purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

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
Exploit Intelligence Platform — CVE, Vulnerability and Exploit Database A
com.exploit-intel
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
Security Penetration Testing Monitoring
2
Vulnerability Intel MCPOAuth
net.nexlab
Defensive vulnerability intelligence search across public CVE/NVD and GitHub advisory APIs with CVSS
Penetration Testing Security
1

Related MCP Servers

mcp-nvd
Security Databases
marcoeg
A
license
B
quality
D
maintenance
A Model Context Protocol server implementation to query the NIST National Vulnerability Database (NVD) via its API.
Updated a year ago (2025-03-24 09:06 UTC)
2
15
MIT
MCP NVD Server
Monitoring Security Documentation Access
gkhays
A
license
B
quality
D
maintenance
A Model Context Protocol server that retrieves CVE information from the National Vulnerability Database, allowing AI models to access up-to-date vulnerability data.
Updated a year ago (2025-05-16 20:56 UTC)
1
7
Apache 2.0
MCP Vulnerability Checker
Security Testing & QA Tools
firetix
A
license
A
quality
D
maintenance
A Model Context Protocol server providing security vulnerability intelligence tools including CVE lookup, EPSS scoring, CVSS calculation, exploit detection, and Python package vulnerability checking.
Updated a year ago (2025-05-23 02:32 UTC)
8
9
MIT
NVD MCP Server
Government Data Search
Alig1493
A
license
A
quality
C
maintenance
MCP server for the NIST National Vulnerability Database — lets AI assistants search CVEs by keyword, severity, CPE, CWE, KEV status, and date range via natural language.
Updated 3 months ago (2026-05-26 23:44 UTC)
2
GPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cyreslab-AI/nist-nvd-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server