pg-cve-mcp
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Each 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.
Naming Consistency4/5Seven 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.
Tool Count5/5Eight 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.
Completeness4/5The 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.
Average 4/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
Tools from this server were used 30 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- 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 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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- 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 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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- 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 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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/meob/PG_CVE-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server