osv-advisory-mcp-server
Server Details
Query OSV.dev for package vulnerabilities and batch-audit dependency lists via MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 4 of 4 tools scored.
Each tool has a distinct purpose: fetching a full advisory, listing ecosystems, querying a single package, and batch querying. There is no overlap or ambiguity.
All tools follow a consistent 'osv_verb_noun' pattern (e.g., osv_get_vulnerability, osv_query_batch), making naming predictable and easy to understand.
With 4 tools, the server is tightly scoped to core OSV lookups—single query, batch query, advisory details, and ecosystem discovery—without unnecessary bloat.
The tool surface covers the primary workflow: discovering ecosystems, querying single or multiple packages, and retrieving full advisory records. No obvious gaps for the intended use case.
Available Tools
4 toolsosv_get_vulnerabilityOsv Get VulnerabilityARead-onlyIdempotentInspect
Fetch the full advisory record for an OSV vulnerability ID. Returns the complete record: summary, full details text, CVE aliases, all affected packages and version ranges, fix versions, CVSS severity vectors, CWE weakness IDs, and references. Use when osv_query_package or osv_query_batch returns a vuln ID and you need the full advisory context — eligibility criteria, scope of affected packages, or remediation guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | OSV vulnerability ID. Accepts any prefix: "GHSA-" (GitHub), "PYSEC-" (Python), "RUSTSEC-" (Rust), "GO-" (Go), "DSA-"/"DLA-" (Debian), "CVE-" (fallback direct lookups). Example: "GHSA-29mw-wpgm-hmr9". |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | OSV vulnerability ID. |
| cweIds | Yes | CWE weakness classifications (e.g. ["CWE-79"]). Present on GitHub Advisory Database records; empty otherwise. |
| aliases | Yes | Alternative IDs — usually CVE IDs. Accepted by nvd_get_cve on nist-nvd-mcp-server for CVSS base score, EPSS exploitation probability, and CISA KEV status. |
| details | Yes | Full advisory text, typically in Markdown. May include proof-of-concept, reproduction steps, or remediation guidance. |
| summary | Yes | One-line advisory description. |
| affected | Yes | All affected packages and their version ranges. An advisory may span multiple packages or ecosystems. |
| modified | Yes | ISO 8601 timestamp of last modification. |
| severity | Yes | CVSS severity entries. Empty for unscored advisories. |
| published | Yes | ISO 8601 timestamp when published. |
| withdrawn | No | ISO 8601 timestamp when this advisory was withdrawn. Present ONLY on withdrawn advisories — a withdrawn record has been retracted and must not be treated as an active vulnerability. |
| references | Yes | Advisory references — NVD links, patches, vendor advisories, PoC reports. |
| schemaVersion | Yes | OSV schema version this record conforms to (e.g. "1.7.3"). |
| severityLabel | Yes | Human-readable severity label ("LOW", "MODERATE", "HIGH", "CRITICAL"). Present on GHSA-sourced records; null when not available. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and not open-world. The description adds value by detailing exactly what information is returned (summary, details, aliases, versions, fixes, CVSS, CWE, references), which goes beyond the annotations' safety indications.
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: first sentence states purpose and return value, second sentence gives usage guidance. It is front-loaded and contains no unnecessary words, perfectly balancing completeness and conciseness.
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 tool has a single parameter with full schema coverage, an output schema, and rich annotations, the description provides all necessary context: what the tool does, when to use it, and what it returns. No gaps are present.
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?
Schema description coverage is 100%—the single parameter 'id' already has a thorough description including prefixes and an example. The tool description does not add new information about the parameter, but since the schema fully covers it, a baseline of 3 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 'Fetch' and clearly states the resource 'full advisory record for an OSV vulnerability ID'. It also lists what the record contains and distinguishes from siblings by specifying the use case when osv_query_package or osv_query_batch returns a vuln ID.
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 explicitly tells when to use this tool: 'Use when osv_query_package or osv_query_batch returns a vuln ID and you need the full advisory context...' This provides clear context and implicitly excludes cases where just the ID or summary is enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
osv_list_ecosystemsOsv List EcosystemsARead-onlyIdempotentInspect
Return the list of supported ecosystem identifier strings for use with osv_query_package and osv_query_batch. Ecosystem strings are case-sensitive exact matches — passing "pypi" instead of "PyPI" returns an error from the API. Use this tool to discover valid ecosystem strings before querying, or to verify an ecosystem identifier from a lockfile format. The list is static (maintained from the OSV schema spec) and may occasionally lag newly added ecosystems.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Advisory note about list currency and canonical source. |
| ecosystems | Yes | Supported ecosystem identifier strings. These are case-sensitive exact matches required by the ecosystem parameter of osv_query_package and osv_query_batch. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds context: the list is static, from OSV schema, may lag. No contradictions. Could mention response format, but output schema exists.
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?
Three sentences, front-loaded with main purpose, no unnecessary words. Efficient and clear.
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 zero-parameter tool with output schema and annotations, description covers purpose, usage, and behavioral traits adequately. No gaps.
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?
No parameters; baseline 4 applies. Description correctly notes the list is static and case-sensitive, which relates to usage of the tool's output, not parameters.
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 it returns the list of supported ecosystem identifier strings for use with other tools. It specifies the resource and verb, and differentiates from siblings which are about querying vulnerabilities or packages.
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?
Explicitly mentions when to use: before querying or to verify ecosystem identifiers. Lacks explicit when-not-to-use or alternatives, but context is clear enough for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
osv_query_batchOsv Query BatchARead-onlyIdempotentInspect
Query vulnerabilities for multiple packages in one call — the primary tool for dependency audits, SBOM scanning, and lockfile triage. Pass an array of {name, ecosystem, version} tuples (up to 1000). Each entry in the response corresponds positionally to the input. Each finding includes CVE aliases for chaining to nist-nvd-mcp-server for CVSS scoring.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | Yes | Packages to audit. One entry per dependency. Positional: result[i] corresponds to packages[i]. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Present on all-clean or all-errors batches — the aggregate outcome for content-only clients. |
| results | Yes | Per-package results, positionally matching the input array. |
| summary | Yes | Aggregate statistics across the full batch. |
| effectiveQuery | No | Compact scan summary (package and outcome counts), echoed on edge-case batches for content-only clients. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, so the agent knows it's safe and idempotent. The description adds behavioral context: positional correspondence between input and output, and that each finding includes CVE aliases for chaining. This goes beyond annotations without contradiction.
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 efficient sentences with no wasted words. It front-loads the primary purpose and includes essential details in a logical order.
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 complexity of a batch query tool with a sibling single-query tool, the description covers: purpose, usage context, input format with limits, output structure (positional), and chaining suggestion for further scoring. The presence of an output schema (not shown) further complements the description. No gaps are apparent.
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?
Schema coverage is 100% with descriptions for all three fields. The description adds value by explaining the tuple structure, the limit of 1000 items (also in schema), and the positional correspondence of results. This additional semantics warrants a score above the baseline of 3.
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 'Query vulnerabilities' as the verb and specifies 'multiple packages' as the resource. It distinguishes itself from sibling tools by being 'the primary tool for dependency audits, SBOM scanning, and lockfile triage' and implicitly contrasts with osv_query_package for single queries.
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 explicitly mentions 'the primary tool for dependency audits, SBOM scanning, and lockfile triage', providing clear context for when to use this tool. It also hints at chaining to nist-nvd-mcp-server for CVSS scoring. While it doesn't state exclusions or alternatives explicitly, the context is strong enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
osv_query_packageOsv Query PackageARead-onlyIdempotentInspect
Query known vulnerabilities for a single package version across any supported ecosystem. Returns all matching OSV advisories with severity (CVSS vectors), CVE aliases, affected version ranges, and first safe version. Use osv_list_ecosystems to validate the ecosystem string before querying — ecosystem strings are case-sensitive exact matches and an invalid value returns an error, not empty results.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name as it appears in the ecosystem (e.g. "express", "requests", "serde"). Case-sensitive. | |
| version | Yes | Package version to check (e.g. "4.17.1", "3.1.4", "1.0.0"). Must be an exact version string, not a range. | |
| ecosystem | Yes | Ecosystem identifier. Must be an exact match (case-sensitive). Use osv_list_ecosystems to see valid values. Examples: "npm", "PyPI", "crates.io", "Go", "Maven", "NuGet". |
Output Schema
| Name | Required | Description |
|---|---|---|
| vulns | Yes | Vulnerabilities matching this package version. An empty array means no known vulnerabilities ONLY when truncated is false. |
| notice | No | Present on the clean path — confirms no known vulnerabilities for the queried package. |
| queryMeta | Yes | Query parameters as submitted. |
| truncated | Yes | True when OSV returned more result pages than the fetch cap could follow — the vulnerability list may be INCOMPLETE. A truncated empty list is NOT a clean result; raise OSV_QUERY_MAX_PAGES or narrow the query. |
| effectiveQuery | No | The package@version (ecosystem) tuple as queried, echoed for content-only clients. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral details beyond annotations: it returns all matching OSV advisories with severity, CVE aliases, affected ranges, and first safe version. It also warns that invalid ecosystem strings cause errors rather than empty results. Annotations (readOnly, idempotent) are consistent.
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?
Two sentences: first states purpose and output, second provides a crucial usage tip. No unnecessary words, well 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?
For a query tool with a single well-defined purpose, the description covers input constraints and output highlights. Output schema exists, so return values need not be fully detailed. Minor gap: doesn't explicitly state behavior when no vulnerabilities found (likely empty result).
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?
Schema coverage is 100%, each parameter has a description. The description reinforces case-sensitivity but does not add significant meaning beyond the schema. Baseline 3 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 clearly states the tool queries known vulnerabilities for a single package version across any supported ecosystem. It distinguishes itself from sibling tools like osv_query_batch (batch) and osv_get_vulnerability (single vulnerability detail) by specifying its 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?
Provides explicit guidance to use osv_list_ecosystems for validating the ecosystem string, and warns that invalid ecosystems return errors. However, it doesn't explicitly compare to other sibling tools or say when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!