This server provides AI agents with direct, programmatic access to PostgreSQL security intelligence, including CVEs, release safety, and upgrade recommendations.
get_cves(version) — Lists all CVEs affecting a specific PostgreSQL version, sorted by CVSS score.
get_version_status(version) — Provides a comprehensive security summary for a version: EOL/yanked status, CVE count, max CVSS, exploit count, and latest minor release.
compare_versions(v1, v2) — Compares CVE profiles of two versions, showing fixed, new, and still-present CVEs.
get_upgrade_path(from_version) — Recommends the next upgrade target (minor update or major migration if branch is EOL/near-EOL).
get_yanked_versions() — Lists all PostgreSQL releases flagged as yanked due to serious bugs.
get_exploits() — Lists all CVEs with known public exploits, sorted by CVSS.
get_latest_minor(major) — Finds the latest minor release in a given major branch.
get_summary() — Provides an overview of the tracked CVE database, including counts and EOL/yanked statistics.
Provides tools for querying PostgreSQL CVEs, version status, upgrade paths, and exploits for any PostgreSQL version.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pg-cve-mcp What CVEs affect PostgreSQL 16.4?"
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.
Give your AI assistant direct access to PostgreSQL security intelligence: CVEs, yanked releases, known exploits, and upgrade paths for any version — queried, not browsed.
Browsing a CVE dashboard is a human habit. Agents need answers, not pages.
pg-cve-mcp turns the curated dataset of the PG_CVE project — the same one powering the PostgreSQL CVE Dashboard — into MCP tools that any AI assistant (opencode, Claude Desktop, etc.) can call directly. What was a static page becomes a first-class, programmatic part of your AI workflow.
Unlike raw NVD feeds, the PG_CVE dataset is manually curated to carry the same judgment a careful DBA would apply:
Yanked releases flagged with the real reason (e.g. "Data corruption using CONCURRENTLY")
Known exploits confirmed to exist in the wild
EOL branches marked, with a synthetic CVE-EOL-WARNING (CVSS 10.0) prepended to unsupported reports
Verified CVEs — no false positives from automated scraping
Prompt to your agent | Tool used | Result |
"Is PostgreSQL 15.8 safe?" |
| EOL/yanked flags, release date, full CVE list sorted by CVSS |
"Compare 16.3 vs 16.4" |
| fixed / new / still-present CVEs with release dates |
"Should I upgrade from 14.10?" |
| recommended target + the CVEs it fixes + release dates |
"Any known exploits right now?" |
| all exploitable CVEs, sorted by CVSS, with release dates |
"What does this database track?" |
| stats, EOL and yanked-release overview |
Every tool returns structured JSON, sorted by CVSS (highest first). Tools flag yanked and EOL state explicitly on the version metadata, and include release dates for every version. get_upgrade_path distinguishes a safe minor upgrade from a forced major one when a branch is at or near end-of-life — so the agent can give advice, not just data.
See real tool outputs in the live demo.
Related MCP server: Postgres Scout MCP
pip install pg-cve-mcp
pg-cve-mcpOr with npx (no install):
npx -y pg-cve-mcpTool | Description |
| Complete security report for a version: EOL/yanked status, release date, stats, CVEs sorted by CVSS (a synthetic |
| Side-by-side CVE comparison (fixed/new/still present) with yanked & EOL flags and release dates |
| Recommended upgrade (minor by default; major when EOL or next-to-EOL) with fixed CVEs and release dates |
| All CVEs with known public exploits, sorted by CVSS, with release dates |
| Overview of the tracked CVE database incl. yanked releases |
Run locally over stdio for opencode, Claude Desktop, and other stdio MCP clients:
pip install -e .
pg-cve-mcpFor remote or enterprise deployments, serve the same tools over HTTP. Run
python run_server.py (or build the Dockerfile); the server listens on $PORT
(default 8000) at path /mcp:
python run_server.py
# MCP endpoint: http://127.0.0.1:8000/mcpConfigure any MCP client with the URL, e.g. in opencode.json:
{
"mcp": {
"pg-cve-mcp": {
"type": "remote",
"url": "http://127.0.0.1:8000/mcp"
}
}
}Env Var | Default | Description |
|
| Cache TTL in seconds for CVE data |
|
| CVE data source URL |
|
| HTTP port for the Streamable HTTP server ( |
Run the test suite and linters:
python -m pytest
ruff check src tests
mypy srcData is fetched from the PG_CVE project's GitHub Pages with local caching. Falls back to a bundled copy if the network is unavailable.
"What CVEs affect PostgreSQL 16.4?"
"Is PostgreSQL 15.8 safe to use?"
"Compare CVEs in 16.3 vs 16.4"
"What's the upgrade path from PostgreSQL 14.10?"
Apache 2.0
Compare the CVE profiles of two PostgreSQL versions side by side.
Shows CVEs fixed in v2 (present in v1 but not v2), new CVEs in v2, and CVEs still present in both.
Args: v1: First PostgreSQL version (e.g. "16.3"). v2: Second PostgreSQL version (e.g. "16.4").
| Name | Required | Description | Default |
|---|---|---|---|
| v1 | Yes | ||
| v2 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It goes beyond a vague 'compare' by specifying exactly what the output contains: CVEs fixed in v2, new CVEs in v2, and CVEs present in both. This is meaningful behavioral context, though it does not mention edge cases or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-line purpose, a succinct list of what it shows, and a compact Args section with examples. Every sentence contributes value with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and minimal parameter schema, the description must be self-sufficient. It adequately covers the purpose, return categories, and parameter meanings. It is complete enough for a straightforward comparison tool, though it could mention what happens with identical or invalid versions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (only type string and titles), and schema coverage is 0%. The description compensates by explaining each parameter: 'v1: First PostgreSQL version (e.g. "16.3")' and similarly for v2, including example formats. This adds crucial meaning beyond the schema, though it stops short of specifying constraints like valid version ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Compare the CVE profiles of two PostgreSQL versions side by side.' It enumerates the three distinct output categories (fixed, new, present in both), which distinguishes it from siblings like get_cves or get_summary that likely handle single versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you need to compare two versions' CVE profiles. It mentions 'side by side' and lists the comparison outcomes, but it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all CVEs affecting a specific PostgreSQL version.
Args: version: A PostgreSQL version string (e.g. "16.4", "15.8", "14.0").
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing output format, possible side effects, or interpretation of 'affecting'. The description lacks behavioral context expected for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, stating the action first and then briefly parameter details. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of multiple sibling tools and no output schema or annotations, the description is minimally sufficient for a simple list tool but does not explain the return format or clarify how it differs from related tools like get_exploits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the 'version' parameter by specifying it is a PostgreSQL version string and providing examples (e.g., '16.4', '15.8', '14.0'), which goes beyond the schema's simple string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all CVEs affecting a specific PostgreSQL version, with a specific verb (List), resource (CVEs), and scope (specific version). This distinguishes it from siblings like get_exploits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use the tool (e.g., when needing CVEs for a version), but no explicit alternatives or exclusions are mentioned. Usage is inferred rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all CVEs with known public exploits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly indicates a read-only operation via 'List,' but provides no additional context such as output format, limitations, or whether 'known public exploits' is based on specific sources. This is adequate for a simple list but lacks richer behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's function without any extraneous words. Every part contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool, the description covers the core functionality. However, without an output schema, it might benefit from noting what fields are returned or how results are ordered, but this is not essential given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The baseline is 4 for such cases, and the description adds no parameter info because none exist. This is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'all CVEs with known public exploits,' distinguishing it from sibling tools like get_cves which likely lists all CVEs. The qualifier 'with known public exploits' adds unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when the user wants CVEs that have known public exploits, as opposed to general CVEs (get_cves). However, it does not explicitly state exclusions or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the latest minor release in a given major branch.
Args: major: A PostgreSQL major version (e.g. "16", "17", "18").
| Name | Required | Description | Default |
|---|---|---|---|
| major | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description and tool name indicate a read-only lookup, but no annotations are present, so the description must carry the burden. It does not disclose behavior for invalid major versions, whether pre-releases are included, or the exact return format. The basic operation is clear, but edge-case behavior is left unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two lines: a clear purpose sentence followed by an arguments block. Every word earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description covers the core use. However, since there is no output schema, the return type is not explicitly stated, and edge cases (e.g., major version not found) are not addressed. Still, it is largely complete for a straightforward lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'major' as a string with no description. The description compensates by specifying it as 'A PostgreSQL major version' and giving concrete examples like '16', '17', '18', which is valuable beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Find the latest minor release in a given major branch,' which clearly states the action (find), the resource (latest minor release), and the scope (given major branch). This distinguishes it from sibling tools like get_summary or get_cves, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a given major branch' implies this tool is used when you already have a major version and need the smallest update, but it does not explicitly mention alternatives or when not to use it. Sibling tool names suggest other version-related queries, but no comparison is provided. Thus, it provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of the tracked PostgreSQL CVE database.
Returns total unique CVEs, known exploits, yanked releases, active and EOL major counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral aspects such as read-only status, authorization needs, or any limitations. The word 'overview' implies a read operation, but the description carries the full burden and does not explicitly state safety or side-effect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It uses three short sentences to state the purpose and output, with no wasted words or redundant formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter summary tool, the description adequately lists the main returned metrics. However, it omits the exact response structure or shape, which would improve completeness given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter explanations are needed. Per baseline, this scores 4 since there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning an overview of the tracked PostgreSQL CVE database, listing specific aggregate outputs (total unique CVEs, known exploits, yanked releases, active/EOL counts). It is distinct from sibling tools like get_cves or get_exploits, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. It does not mention that this is for high-level summaries and that detailed data should use get_cves, get_exploits, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest the recommended upgrade target for a PostgreSQL version.
Returns the latest minor in the same branch and, if applicable, suggests upgrading to a newer non-EOL major version.
Args: from_version: The currently installed PostgreSQL version (e.g. "16.3").
| Name | Required | Description | Default |
|---|---|---|---|
| from_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates that the tool returns the latest minor and may suggest a major upgrade, which is useful but does not explicitly state side effects, required permissions, or error behavior. As a 'get' tool, it is likely read-only, but this is not stated explicitly. The description is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a clear one-sentence purpose, then provides a brief behavioral explanation, and ends with a parameter list. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with one parameter, no output schema, and no annotations, so the description must explain the return value. It does describe the general output (latest minor and possible major), but it does not specify the exact return format (e.g., string, object, list) or address edge cases such as what happens if the version is already the latest or is EOL. This leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the parameter, with 0% schema description coverage. The description fully compensates by providing an 'Args' section that explains the parameter 'from_version' as the currently installed PostgreSQL version and gives a concrete example ('16.3'). This adds meaning beyond the schema, which only provides the type and name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to suggest a recommended upgrade target for a PostgreSQL version. It specifies the verb 'suggest' and the resource 'upgrade target', and further clarifies behavior by mentioning the latest minor and possible major upgrade. This distinguishes it from sibling tools like get_latest_minor, which focuses only on the latest minor version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It does not mention any exclusions or prerequisites, and sibling tools such as get_latest_minor or compare_versions offer related functionality without any differentiation. The usage context is only implied by the description of what the tool returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive security status summary for a PostgreSQL version.
Returns EOL status, yanked status, CVE count, max CVSS score, exploit count, and the latest minor in the same branch.
Args: version: A PostgreSQL version string (e.g. "16.4", "15.8").
| Name | Required | Description | Default |
|---|---|---|---|
| version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It indicates a read-only operation with 'Get' and describes the return values, but it does not disclose potential error conditions, rate limits, or data source behavior. This is adequate basic transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a minimal Args block, with the core purpose front-loaded. Each sentence adds necessary information: the main action, the exact output fields, and the parameter format. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently enumerates all returned components and explains the input format. It lacks edge-case handling (e.g., invalid version behavior), but for a single-parameter read-only tool, this is a minor omission. Overall, it provides enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a string parameter named 'version' with no description. The description's Args block fully compensates by specifying the expected format ('PostgreSQL version string') and providing concrete examples ('16.4', '15.8'), making the parameter semantics clear despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a security status summary for a PostgreSQL version and lists the specific fields returned (EOL status, yanked status, CVE count, max CVSS score, exploit count, latest minor). This distinguishes it from sibling tools like get_cves or get_exploits that focus on individual aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a comprehensive security overview is needed, but it does not explicitly contrast it with alternatives like get_summary or get_cves, nor does it state when not to use it. The listed return fields give some context, but no explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all PostgreSQL releases that have been flagged as 'yanked' due to serious regressions or data corruption bugs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately discloses that the tool lists all yanked releases and provides context on why they are yanked. However, it does not mention any side effects, permissions, or limitations, though for a read-only listing tool this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose and scope. No wasted words; every phrase contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter tool with no output schema, the description sufficiently explains what the tool returns (a list of yanked PostgreSQL releases) and the rationale. Sibling tool context adds clarity, but the description alone is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4, and the description adds no parameter-specific information because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource ('all PostgreSQL releases flagged as yanked') plus the reason for yanking. This clearly distinguishes it from sibling tools like get_cves or get_exploits, which focus on security issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve yanked versions, but it does not explicitly state when to use it versus alternatives or provide exclusion criteria. Usage is implied from the purpose rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0compare_versionsget_cvesget_exploitsget_latest_minorget_summaryget_upgrade_pathget_version_statusget_yanked_versionsEach tool targets a distinct purpose: latest minor, summary stats, CVE listing, status summary, comparison, upgrade path, yanked list, and exploits. Some overlap exists between get_latest_minor and get_upgrade_path (both involve latest minor) and between get_cves and get_exploits (both list CVEs), but descriptions clarify the differences.
Seven of eight tools follow the get_<object> pattern (e.g., get_summary, get_yanked_versions), but compare_versions deviates by using a verb_prefix style. The overall pattern is clear and predictable, with only one outlier.
Eight tools is well within the ideal 3–15 range for a domain-specific server. Each tool covers a distinct query or operation relevant to PostgreSQL CVE tracking, with no redundancy or bloat.
The tool set covers core workflows: version lookup, CVE listing, comparison, upgrade suggestions, yanked releases, and exploit lists. Minor gaps include no tool to list all available major versions or fetch individual CVE details, but these are not critical for the server's apparent purpose.
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/meob/PG_CVE-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
