Skip to main content
Glama

nvd

by io.github.pipeworx-io

Search Cves

search_cves
Read-onlyIdempotent

Search NVD for CVE vulnerabilities by product or component name. Returns CVE ID, description, severity, and CVSS score. Search terms are matched against CVE description text and EVERY word must appear, so pass the product name ("OpenSSL", "log4j", "nginx") optionally with a technical term ("buffer overflow") — not a plain-English question. Use when researching security threats or checking if a known vulnerability affects your systems.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (default 10, max 2000)
queryYesProduct, component or technical term to match against CVE descriptions, e.g. "OpenSSL" or "log4j deserialization". Every word must appear in a CVE's description, so question words ("latest critical vulnerabilities in ...") match nothing and are stripped automatically.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cvesYesList of CVE records matching the search
returnedYesNumber of CVEs returned in this response
total_resultsYesTotal number of CVEs matching the search query

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Keyword(s) to search in CVE descriptions"New value: +"Product, component or technical term to match against CVE descriptions, e.g. \"OpenSSL\" or \"log4j deserialization\". Every word must appear in a CVE's description, so question words (\"latest critical vulnerabilities in ...\") match nothing and are stripped automatically."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "cves": {
+      "description": "List of CVE records matching the search",
+      "items": {
+        "properties": {
+          "cvss_score": {
+            "description": "CVSS base score (v3.1 preferred, falls back to v2)",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "description": {
+            "description": "English description of the vulnerability",
+            "type": "string"
+          },
+          "id": {
+            "description": "CVE identifier",
+            "type": "string"
+          },
+          "last_modified": {
+            "description": "Last modification date in ISO 8601 format",
+            "type": "string"
+          },
+          "published": {
+            "description": "Publication date in ISO 8601 format",
+            "type": "string"
+          },
+          "severity": {
+            "description": "Severity rating (CRITICAL, HIGH, MEDIUM, LOW, NONE)",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "status": {
+            "description": "Vulnerability status (e.g., PUBLISHED)",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "published",
+          "last_modified",
+          "status",
+          "description",
+          "cvss_score",
+          "severity"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "returned": {
+      "description": "Number of CVEs returned in this response",
+      "type": "number"
+    },
+    "total_results": {
+      "description": "Total number of CVEs matching the search query",
+      "type": "number"
+    }
+  },
+  "required": [
+    "total_results",
+    "returned",
+    "cves"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "query": "log4j"
+  },
+  {
+    "limit": 50,
+    "query": "Apache Struts remote code execution"
+  }
+]
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses key behavioral subtleties: search terms match against CVE description text, every word must appear (AND logic), and question words are stripped automatically. This gives the agent essential insight into how queries are processed, which is not evident from the annotations or schema.

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

Conciseness5/5

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

The description is a single, focused paragraph with three sentences. It front-loads the purpose, then gives critical usage details, then a clear use-case. Every sentence earns its place with no redundancy or bloat, making it both concise and 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 rich schema, annotations, and output schema, the description fully covers the tool's purpose, query behavior, parameter semantics, and usage context. It lacks only explicit sibling-tool differentiation, but that is not essential for completeness when the purpose and behavior are so clearly stated. Overall, it provides all necessary information for an agent to select and invoke the tool effectively.

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 already covers 100% of parameters with descriptions, so the baseline is 3. The description adds significant extra meaning for the 'query' parameter by explaining the matching semantics (every word must appear, plain-English questions stripped), which directly impacts how the agent constructs queries. The 'limit' parameter is not mentioned in the description, but the schema fully documents it.

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 'Search NVD for CVE vulnerabilities by product or component name' with a specific verb and resource. It distinguishes from sibling tools like get_cve (which likely retrieves a single CVE) and recent_cves (which lists recent vulnerabilities). It also specifies return fields, making the tool's purpose unambiguous.

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?

It provides explicit when-to-use guidance: 'Use when researching security threats or checking if a known vulnerability affects your systems.' It also warns against plain-English questions and explains the AND-matching behavior, which is valuable usage context. However, it does not explicitly name alternative tools or state when not to use this tool vs. get_cve or recent_cves.

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

All nvd toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools have distinct purposes, but some overlap exists (e.g., ask_pipeworx and ask_pipeworx_grounded, deep_research and ask_pipeworx). The Polymarket tools are numerous but clearly differentiated.

Naming Consistency3/5

Mixed naming conventions: some tools start with verbs (ask_pipeworx, search_cves), others with nouns (entity_profile, recent_changes). Prefixes (pipeworx_, polymarket_) help but the pattern is not uniform.

Tool Count2/5

33 tools is excessive for a single server, covering too many domains (NVD, Pipeworx, Polymarket, SEC, memory). This reduces coherence and makes it hard for agents to navigate.

Completeness4/5

Core workflows are covered: CVE lookup, company research, prediction market analysis, and data querying. However, there are minor gaps (e.g., no tool for editing stored data, no CVE metrics beyond search).

Resources