PostgreSQL CVE & Release Intelligence
PostgreSQL security for AI agents: CVEs, yanked releases, exploits, and upgrade paths
The current version, v1.0.4, was published to the official MCP registry on 2026-08-18. It is distributed as pg-cve-mcp on PyPI, filed under Databases by this index, and declares 2 environment variables. Removals and unreachable sources are measured across every server this index tracks, contract drift across the servers that answer in consecutive snapshots; the index's current counts put this record in context.
Using PostgreSQL CVE & Release Intelligence in Claude, Cursor, Gemini CLI, Cline, or Zed?
MCP tool contracts can change remotely with no version bump. The mcpindex gate pins each contract and HOLDs the call when it drifts-before your agent acts. Zero credentials. This is not the package install for this server itself (use Install this server for that).
Rewrites your MCP host config so each server launches behind the gate. Inspect first: curl -fsSL https://mcpindex.ai/install.sh | less
uv tool install mcpindex-gate && mcpindex-config-wireSemantic screen found no manipulation pattern in the description. Conformance probe not yet run.
mcpindex.integrity.descriptionpassINFOevidence“No malicious instructions found”via static_description
- - Semantic screen only - the deterministic conformance probe has not run on this server
- - Confidence is reported but not yet calibrated (v1)
- - Screen reads the tool description, not the live behavior
- - advisory
- - registry description only no input schema
- - screen model 8b
- - Still current: the description we screened is unchanged, re-checked against the registry
- - The registry listing (version, packages, links) changed after this screen ran - the description we assessed did not
Semantic screen: an LLM judge reads the tool description for hidden instructions (status PARTIAL). A pass means the description is not lying, not that the tool is safe: a high-capability tool with an honest description still warrants caution. The deterministic conformance probe has not been run on this server yet, so the screen here is semantic-only. Posture: advisory. Confidences are reported but not yet calibrated (calibrated=false at v1). Full verdict history is not shown on this page.
Own this server? Screen its description →
That verdict was true at screening time (snapshot 2026-09-16).
Contracts can change after screening, with no version bump. The gate pins PostgreSQL CVE & Release Intelligence’s tool contracts on first sight and holds any silent change before your agent acts - the check that keeps being true on Tuesday.
See your first HOLD in 2 minutes →
Related: how to trust an MCP server · screen before install · silent contract drift
People vet a server before wiring it in. One line on your project site or docs answers that with an independent record: screening verdict, registry provenance, contract drift history. It stays current as new screens and drift events land.
[Independent trust record for PostgreSQL CVE & Release Intelligence](https://mcpindex.ai/server/io-github-meob-pg-cve-mcp) - screening verdict, registry provenance, and contract drift monitoring.<a href="https://mcpindex.ai/server/io-github-meob-pg-cve-mcp">Independent trust record for PostgreSQL CVE & Release Intelligence</a> - screening verdict, registry provenance, and contract drift monitoring.A live verdict badge for your README or listing. It reflects the current screen, links back here, and updates when the verdict does.
[](https://mcpindex.ai/server/io-github-meob-pg-cve-mcp)<a href="https://mcpindex.ai/server/io-github-meob-pg-cve-mcp"><img src="https://mcpindex.ai/api/v1/badge/io-github-meob-pg-cve-mcp" alt="mcpindex verdict" height="20" /></a>PG_CVE_MCP_TTLCache TTL in seconds for CVE data refresh (default: 86400)
PG_CVE_MCP_DATA_URLURL of the PostgreSQL CVE JSON data (default: PG_CVE GitHub Pages)
Provision PostgreSQL, manage Apache Kafka, and deploy apps with Aiven - all from your AI assistant.
FinOps MCP: query allocated, correlated cloud and AI cost across AWS, GCP, Azure and Snowflake.
112 rules that catch dangerous PostgreSQL migrations, plus a pass/fail gate to call before any DDL.