How do I use Vulnerability Registry 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., "@Vulnerability Registry MCP Server What is the CVSS score and status of CVE-2021-44228?" 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.

Vulnerability Registry MCP Server

by MalkiLevinzon

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Vulnerability Registry MCP Server

A TypeScript MCP server that exposes a legacy, file-based vulnerability registry to MCP-compatible LLM clients. The server parses versioned pipe-delimited files at startup, validates referential integrity, builds in-memory indexes, and exposes focused tools for CVE lookup, search, vendor navigation, and aggregate statistics.

Architecture

Legacy DB files
      ↓
Version-aware parser
      ↓
Validated domain models
      ↓
In-memory registry and indexes
      ↓
MCP tools over stdio

The parser reads FORMAT dynamically, so the implementation does not depend on a fixed column order. Version-specific parsing is selected through a parser registry. Raw parsing and domain mapping are deliberately separated: the parser understands file structure, while mappers validate business meaning such as CVE syntax, CVSS range, status, severity, and dates.

Related MCP server: nvd-cve-mcp-server

Requirements

Node.js 20 or newer
npm

Install and run

npm ci
npm run build
npm start

Development mode:

npm run dev

All logs are written to stderr; stdout remains reserved for MCP stdio traffic.

Configuration

Optional environment variables:

VENDORS_DB_PATH
VULNERABILITIES_DB_PATH
DEFAULT_PAGE_SIZE (default: 20)
MAX_PAGE_SIZE (default: 100)

Tools

`get_vulnerability`

Retrieves one vulnerability by exact CVE identifier.

Example: What is the CVSS score and status of CVE-2021-44228?

`search_vulnerabilities`

Searches and filters by free text, vendor, severity, status, CVSS range, publication dates, sorting, and pagination.

Example: Which open Linux Kernel vulnerabilities have CVSS 7 or higher?

`search_vendors`

Finds vendors by name, category, or headquarters and includes useful counts.

`get_vendor_overview`

Returns vendor details, aggregate statistics, and the five most recent vulnerabilities.

`get_vulnerability_statistics`

Returns counts by status and severity plus CVSS minimum, maximum, and average without returning every matching row.

Example: How many critical vulnerabilities are still open?

Validation policy

Startup fails when data cannot be trusted, including:

unsupported database version;
missing metadata or required columns;
malformed row field counts;
invalid CVE, CVSS, status, severity, date, or founded year;
duplicate vendor IDs, vulnerability IDs, or CVE IDs;
vulnerability references to missing vendors.

This fail-fast policy avoids plausible but incomplete security answers.

Performance

The files are loaded once at startup. Exact lookups and joins use:

vendorsById;
vulnerabilitiesByCve;
vulnerabilitiesByVendorId.

For the expected scale of thousands of records, compound text filtering remains a simple in-memory scan. This is easier to reason about and maintain than introducing a search dependency prematurely. Pagination and deterministic sorting prevent oversized or unstable responses.

affected_versions is intentionally kept as free text. The source format does not define a formal version-range grammar, so the server supports text search but does not claim semantic range evaluation.

Quality checks

npm run typecheck
npm run lint
npm test
npm run build
npm run check

To inspect the MCP server interactively:

npm run inspect

Claude Desktop configuration

Build first, then add an absolute path:

{
  "mcpServers": {
    "vulnerability-registry": {
      "command": "node",
      "args": ["/absolute/path/to/vulnerability-registry-mcp/dist/src/index.js"]
    }
  }
}

Design decisions

Modular monolith rather than a framework-heavy application.
No dependency-injection container; dependencies are passed explicitly from the composition root.
No repository interface until a second persistence implementation exists.
MCP handlers contain transport concerns only; all querying lives in VulnerabilityRegistry.
Errors are typed and translated to safe MCP error payloads without leaking stack traces.
Both text content and machine-readable structuredContent are returned.

With more time

I would add atomic hot reload when source files change, richer full-text indexing, support for additional format versions, audit logging, operational metrics, and a dedicated natural-language agent client. For a remotely hosted deployment, I would add authentication, authorization, rate limiting, and Streamable HTTP transport.

Production-oriented AI agent stack

This repository now includes an optional end-to-end stack:

Open WebUI
    ↓ OpenAI-compatible HTTP (/v1/chat/completions)
TypeScript Agent Service
    ↓ MCP Streamable HTTP
Vulnerability Registry MCP Server
    ↓
Validated in-memory registry loaded from the legacy .db files

The original stdio entry point remains available for local MCP clients. The remote entry point is src/http.ts, and the OpenAI-compatible agent entry point is src/agent/http-server.ts.

Why the Agent Service exists

Open WebUI is the user interface, not the MCP client that contains the application-specific orchestration policy. The Agent Service:

exposes /v1/models and /v1/chat/completions, which Open WebUI understands;
connects to the MCP server and discovers its tools dynamically;
gives those tool schemas to an OpenAI-compatible model provider;
executes requested MCP tool calls;
returns the final grounded answer to Open WebUI;
keeps model-provider credentials out of the browser;
applies authentication, timeouts, request-size limits and a maximum number of tool rounds.

Important: ChatGPT Plus and API billing

A ChatGPT Plus subscription is separate from OpenAI API usage. To use an OpenAI model through this Agent Service, create an API key and enable API billing separately. The Agent Service is provider-neutral: LLM_BASE_URL, LLM_API_KEY and LLM_MODEL can point to another OpenAI-compatible provider instead.

HTTP MCP entry point

Run the remote MCP server:

npm run build
MCP_API_KEY=local-mcp-key npm run start:http

Endpoints:

POST /mcp — stateless MCP Streamable HTTP transport
GET /health — process liveness
GET /ready — verifies that the registry files can be loaded and validated

Environment variables:

Variable	Default	Purpose
`MCP_HTTP_HOST`	`0.0.0.0`	Bind address
`MCP_HTTP_PORT`	`8080`	HTTP port
`MCP_API_KEY`	unset	Optional bearer token required by `/mcp`

Agent Service

Run it after the HTTP MCP server is available:

LLM_API_KEY=replace-me \
MCP_URL=http://localhost:8080/mcp \
MCP_API_KEY=local-mcp-key \
AGENT_API_KEY=local-agent-key \
npm run start:agent

Main environment variables:

Variable	Default	Purpose
`AGENT_PORT`	`8081`	Agent HTTP port
`AGENT_API_KEY`	unset	Bearer token accepted from Open WebUI
`AGENT_MODEL_ID`	`vulnerability-agent`	Model name shown in Open WebUI
`MCP_URL`	`http://localhost:8080/mcp`	Remote MCP endpoint
`MCP_API_KEY`	unset	Token sent to the MCP server
`LLM_BASE_URL`	`https://api.openai.com/v1`	OpenAI-compatible provider base URL
`LLM_API_KEY`	required	Provider API key
`LLM_MODEL`	`gpt-4.1-mini`	Provider model used for reasoning/tool calls
`MAX_TOOL_ROUNDS`	`8`	Prevents unbounded tool loops
`REQUEST_TIMEOUT_MS`	`60000`	Provider request timeout

Docker Compose

Copy the example environment file and replace every placeholder:

cp .env.example .env

On PowerShell:

Copy-Item .env.example .env

Start the full stack:

docker compose up --build

Open WebUI at http://localhost:3000. On first launch, create the admin user. Then open:

Admin Settings → Connections → OpenAI → Add Connection

Configure:

URL:     http://agent:8081/v1
API key: the value of AGENT_API_KEY in .env
Model:   vulnerability-agent

The Docker network resolves the hostname agent from the Open WebUI container. Do not use localhost:8081 in this screen because, inside the Open WebUI container, localhost refers to Open WebUI itself.

Why PostgreSQL is included

PostgreSQL is not needed for the vulnerability registry itself in the current assignment. The legacy files are loaded once, validated and indexed in memory, which is appropriate for the stated scale of thousands of records.

PostgreSQL is included for Open WebUI persistence. It stores application state such as:

users and authentication records;
chat history;
saved settings and model connections;
permissions and shared UI objects.

For one local demo instance, Open WebUI can use its built-in SQLite database and PostgreSQL may be removed from docker-compose.yml. For a production deployment with multiple workers or replicas, PostgreSQL is the safer choice because SQLite does not support concurrent writes from several application instances and should not be placed on shared network storage.

The Agent Service itself is deliberately stateless. It does not need PostgreSQL merely to call MCP tools. A future version could add agent-owned tables for audit records, feedback, conversation checkpoints, usage accounting or idempotency, but those concerns should be added only when required rather than coupling them to the vulnerability data.

Production notes

Pin the Open WebUI image to a tested release before deployment; do not use a floating development tag.
Replace all example secrets and store them in a secret manager in hosted environments.
Terminate TLS at a reverse proxy or ingress and do not expose plain HTTP publicly.
Add rate limiting at the gateway/ingress layer.
The HTTP MCP server is stateless, so replicas can be scaled horizontally without session affinity.
The current streaming response is OpenAI-compatible but buffered: the Agent completes its tool loop before emitting one SSE content chunk. Token-by-token provider streaming can be added later without changing the Open WebUI contract.

Available Tools

5 tools

get_vendor_overviewGet vendor overviewA

Return one vendor, aggregate vulnerability statistics, and its five most recent vulnerabilities. Use after identifying a vendor ID.

ParametersJSON Schema

Name	Required	Description	Default
`vendorId`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`vendor`	Yes
`statistics`	Yes
`recentVulnerabilities`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently describes what the tool returns: one vendor, aggregate vulnerability statistics, and the five most recent vulnerabilities. It doesn't mention error behavior or permissions, but for a simple read operation, the disclosed behavior is sufficient.

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 just two sentences, front-loading the primary action in the first sentence and usage context in the second. Every word contributes value; there is no filler or redundancy.

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 tool's moderate complexity and the presence of an output schema, the description covers essential aspects: what is returned (vendor, stats, recent vulns) and when to use it (after vendor ID identification). It doesn't cover edge cases like not-found behavior, but the usage instruction and output schema make the description sufficiently complete.

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 schema provides only a 'vendorId' string with no description (0% coverage), so the description must compensate. The phrase 'Use after identifying a vendor ID' clarifies that vendorId is the identifier of the vendor to fetch, which is sufficient for a single-parameter tool.

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 begins with 'Return one vendor, aggregate vulnerability statistics, and its five most recent vulnerabilities,' which clearly states the tool's function with a specific verb and resource. It also distinguishes itself from sibling tools like search_vendors and get_vulnerability by combining vendor details with statistics and recent vulnerabilities.

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

Usage Guidelines4/5

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

The phrase 'Use after identifying a vendor ID' provides an explicit precondition for when to invoke this tool. While it doesn't explicitly contrast with siblings, the context signals and the instruction make it clear that this is for post-identification overview rather than discovery or individual vulnerability lookup.

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

get_vulnerabilityGet vulnerabilityA

Retrieve one vulnerability by its exact CVE identifier. Use for score, status, vendor, affected versions, title, or publication date of a specific CVE.

ParametersJSON Schema

Name	Required	Description	Default
`cveId`	Yes	Exact identifier such as CVE-2021-44228

Output Schema

ParametersJSON Schema

Name	Required	Description
`vulnerability`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior. It states it retrieves data but does not mention error handling, authentication, rate limits, or what happens if the CVE is not found. The list of fields provides some context about the response, but the behavioral surface is minimal. Given the simplicity, a score of 3 is reasonable.

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 two sentences, front-loaded with the primary action and constraint. Every word adds value, with no filler.

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 single required parameter and an existing output schema, the description sufficiently explains when to use the tool and what data it returns. The mention of specific fields and exact CVE identifier covers the prerequisites. The output schema handles return structure.

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 already provides a full description of cveId with an example. The tool description only restates 'exact CVE identifier,' adding no new semantic information. Since schema coverage is 100%, the baseline of 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's action ('Retrieve one vulnerability') and the key constraint ('by its exact CVE identifier'), distinguishing it from sibling search_vulnerabilities. It also lists the specific fields the caller can access, which reinforces the purpose.

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 implies the tool is for a single known CVE, saying 'exact CVE identifier' and listing details like score, status, and vendor. However, it does not explicitly mention alternative tools or when not to use it, though the word 'exact' suggests searching is for unknown CVEs. This is a clear context but lacks explicit exclusions.

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

get_vulnerability_statisticsGet vulnerability statisticsA

Count and summarize vulnerabilities without returning every matching record. Use for questions such as how many critical vulnerabilities are open.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No
`severity`	No
`vendorId`	No
`vendorName`	No
`publishedTo`	No
`publishedFrom`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`cvss`	Yes
`total`	Yes
`byStatus`	Yes
`bySeverity`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: 'without returning every matching record', implying aggregate output and non-destructive reads. However, it does not explain aggregation specifics (e.g., grouping, pagination) or any permissions/limits. This is adequate but not thorough.

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 two sentences, with the primary action and resource stated immediately. It avoids fluff and every sentence contributes: the first defines behavior, the second gives a use-case example.

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 an output schema present, return values need not be described. The description gives a clear purpose and one usage example, but with no annotations and six parameters (all optional) lacking schema descriptions, the tool definition feels slightly under-specified for a fully self-contained agent evaluation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only implicitly references 'critical' and 'open' parameters. Parameter names and enums in the schema provide some self-evident meaning, but the description adds virtually no parameter-level detail beyond what the schema already shows.

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 uses specific verbs 'Count and summarize' with the resource 'vulnerabilities', clearly distinguishing this aggregation tool from sibling tools like get_vulnerability and search_vulnerabilities, which return records. It also gives an example question ('how many critical vulnerabilities are open') that reinforces the purpose.

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 clearly states when to use this tool: for questions requiring counts or summaries rather than full matching records. It provides a concrete example, but does not explicitly name alternatives or state when not to use it, so it misses the bar for a 5.

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

search_vendorsSearch vendorsA

Find vendors by name, category, or headquarters and return vulnerability counts.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`offset`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	Yes
`limit`	Yes
`total`	Yes
`offset`	Yes
`hasMore`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It discloses the output (vulnerability counts) but does not explain query behavior (e.g., matching semantics, case sensitivity), pagination via limit/offset, or what happens with no results. This is minimal behavioral disclosure.

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 conveys the core purpose and output without unnecessary words. It is concise and well-structured.

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 an output schema and only 3 parameters, the description is minimally complete for a search tool. However, it lacks context on when to use it versus get_vendor_overview, and it does not specify pagination behavior or query nuance. The presence of an output schema helps, but the description still leaves gaps.

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 0%, so the description must compensate. It explains the 'query' parameter can contain name, category, or headquarters, adding meaning. However, it does not clarify the relationship between these search criteria (e.g., separate fields vs. combined search) or explain limit/offset, though those have schema defaults and constraints.

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 uses the specific verb 'Find' and clearly identifies the resource (vendors). It specifies search criteria (name, category, or headquarters) and the return value (vulnerability counts). This differentiates it from siblings like search_vulnerabilities and get_vendor_overview.

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 when to use the tool (when searching for vendors by attributes), but it does not provide explicit alternatives or exclusions. It does not contrast with get_vendor_overview or search_vulnerabilities, leaving some ambiguity for the agent.

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

search_vulnerabilitiesSearch vulnerabilitiesA

Search and filter vulnerabilities by text, vendor, severity, status, CVSS score, or publication date. Use this for lists of matching CVEs.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	No
`offset`	No
`sortBy`	No	published
`status`	No
`severity`	No
`vendorId`	No
`vendorName`	No
`publishedTo`	No
`maxCvssScore`	No
`minCvssScore`	No
`publishedFrom`	No
`sortDirection`	No	desc

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	Yes
`limit`	Yes
`total`	Yes
`offset`	Yes
`hasMore`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation through 'Search and filter,' but does not explicitly state that it does not modify data, nor does it mention pagination behavior or return format (though output schema exists). The description adds some context beyond the schema (e.g., returns lists) but lacks depth about side effects or edge cases.

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 exactly two sentences: the first states the action and filter dimensions, the second clarifies the use case. Every word earns its place with no redundancy or irrelevant detail, making it highly efficient and front-loaded.

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 tool's complexity (13 optional parameters, many enums, output schema), the description covers the essential context: the purpose, main filter categories, and the fact that it returns lists. The output schema covers return-value structure, and the filter dimensions are enumerated. It lacks explicit details about default pagination or search semantics, but this is adequately handled by the schema and the concise use-case note.

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 0%, so the description must compensate. It groups parameters into conceptual filters (text, vendor, severity, status, CVSS score, publication date), which adds high-level meaning. However, it stops short of mapping each filter to specific parameter names (e.g., 'text' → query) or explaining nuances like date range pairs, so it only partially clarifies the 13 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 uses a specific verb ('Search and filter') and identifies the resource ('vulnerabilities') with an explicit list of filter dimensions (text, vendor, severity, status, CVSS score, publication date). The phrase 'Use this for lists of matching CVEs' distinguishes it from sibling tools like get_vulnerability, indicating this is for list retrieval rather than single-record lookup.

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 provides clear usage context by stating 'Use this for lists of matching CVEs,' which tells the agent when to select this tool. It does not explicitly name alternatives or exclude cases, but the list-focused guidance is sufficient given the sibling tool names (e.g., get_vulnerability). No misleading or contradictory usage advice is present.

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.

5 tool updatesv1.0.0Aug 11, 2026
- First observedget_vendor_overview
- First observedget_vulnerability
- First observedget_vulnerability_statistics
- First observedsearch_vendors
- First observedsearch_vulnerabilities

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct operation: get_vulnerability for a specific CVE, search_vulnerabilities for filtered lists, search_vendors for vendor lookup, get_vendor_overview for aggregate vendor data, and get_vulnerability_statistics for counts. There is no meaningful overlap between any pair of tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase and underscores, with verbs limited to 'get' and 'search'. The naming clearly indicates whether a tool returns a single entity, a list, or statistics.

Tool Count5/5

With 5 tools, the server is well-scoped for a vulnerability registry query interface. Each tool covers a distinct need without redundancy or bloat, fitting comfortably in the ideal 3-15 range.

Completeness5/5

The tool set provides complete read-only coverage for a vulnerability registry: individual CVE lookup, flexible searching, vendor discovery, vendor-specific aggregation, and vulnerability statistics. No obvious gaps exist for the apparent domain.

Maintenance

ActivitySlowing

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

ZEN SecDB A
cloud.nttzen.secdb
ZEN SecDB MCP server for CVE intelligence, CVSS/EPSS scoring, advisories, SSVC, and package audits.
Security Penetration Testing
112
nvd A
io.github.pipeworx-io
NVD MCP — wraps the NIST National Vulnerability Database API (free, no auth)
Security Government Data Open Data
342
Vulnerability Intel MCPOAuth
net.nexlab
Defensive vulnerability intelligence search across public CVE/NVD and GitHub advisory APIs with CVSS
Penetration Testing Security
1
Security Recipes C
io.github.stevologic
Read-only CVE intelligence, remediation playbooks, and agent setup guides. Not a scanner.
Security Documentation Access
7511

Related MCP Servers

cwe-search_mcp
Security Penetration Testing Research & Data
Bilel-Eljaamii
A
license
A
quality
D
maintenance
Enables querying MITRE's Common Weakness Enumeration database for vulnerability information, supporting CWE lookup, search, taxonomy navigation, and relationship mapping through MCP.
Updated a year ago (2025-06-29 09:00 UTC)
9
6
MIT
nvd-cve-mcp-server
Search Open Data
millsks
A
license
A
quality
C
maintenance
MCP server that provides tools to search, filter, and retrieve CVE data from the NVD API, including by ID, keyword, severity, and recency.
Updated a day ago (2026-09-06 06:25 UTC)
4
MIT
cisa-kev-mcp
Government Data Security
CSOAI-ORG
A
license
Not graded
quality
C
maintenance
MCP server to query and manage CISA Known Exploited Vulnerabilities catalog with EPSS overlay, enabling vulnerability checks and remediation deadline tracking.
Updated 2 months ago (2026-06-26 05:28 UTC)
MIT
vulnerability-registry-mcp
Security Search
feldboy
F
license
Not graded
quality
B
maintenance
Enables security analysts and risk managers to query a legacy CVE registry via natural language, providing tools for searching vulnerabilities, retrieving details, and obtaining statistics.
Updated 2 months ago (2026-07-10 12:28 UTC)
-

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/MalkiLevinzon/vulnerability-registry-mcp'

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