Skip to main content
Glama

osv-advisory-mcp-server

by io.github.cyanheads

Osv Get Vulnerability

osv_get_vulnerability
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesOSV 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

TableJSON Schema
NameRequiredDescriptionDefault
idNoOSV vulnerability ID.
errorNoPresent when the call failed. Absent on success.
cweIdsNoCWE weakness classifications (e.g. ["CWE-79"]). Present on GitHub Advisory Database records; empty otherwise.
aliasesNoAlternative 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.
detailsNoFull advisory text, typically in Markdown. May include proof-of-concept, reproduction steps, or remediation guidance.
summaryNoOne-line advisory description.
affectedNoAll affected packages and their version ranges. An advisory may span multiple packages or ecosystems.
modifiedNoISO 8601 timestamp of last modification.
severityNoCVSS severity entries. Empty for unscored advisories.
publishedNoISO 8601 timestamp when published.
withdrawnNoISO 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.
referencesNoAdvisory references — NVD links, patches, vendor advisories, PoC reports.
schemaVersionNoOSV schema version this record conforms to (e.g. "1.7.3").
severityLabelNoHuman-readable severity label ("LOW", "MODERATE", "HIGH", "CRITICAL"). Present on GHSA-sourced records; null when not available.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate those. It adds behavioral context by listing the exact fields returned, which goes beyond the schema's basic parameter documentation. No contradictions with annotations; the description's 'fetch' language aligns with read-only 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/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste: the first states purpose and return content, the second provides usage guidance. The core action is front-loaded, and every phrase adds value.

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?

For a simple single-parameter read tool with annotations and an output schema, the description is thorough. It covers what it does, what it returns, when to use it, and the parameter is fully documented in the schema. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%: the single 'id' parameter has a detailed description including allowed prefixes and an example. The tool description adds no extra semantics about the parameter beyond what the schema already provides, so the baseline score 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 opens with a clear verb-resource pair: 'Fetch the full advisory record for an OSV vulnerability ID.' It enumerates the specific content returned (summary, details, aliases, affected packages, fix versions, CVSS, CWE, references), leaving no ambiguity about the tool's function. It also distinguishes itself from siblings by focusing on full advisory retrieval, contrasting with query or list operations.

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

Usage Guidelines5/5

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

The description explicitly states when to use the tool: '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.' This directly names the source tools and the triggering condition, giving clear decision guidance to an agent.

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

All osv-advisory-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetching by ID, listing ecosystems, querying a single package, and batch querying multiple packages. Even though query_package and query_batch both search for vulnerabilities, they differ in input type and use case, with descriptions explicitly stating the intended scenarios.

Naming Consistency5/5

All tools follow a uniform 'osv_verb_noun' pattern (get_vulnerability, list_ecosystems, query_batch, query_package) with consistent snake_case and no mixing of verb styles. The pattern is immediately predictable and reinforces the distinct actions each tool performs.

Tool Count5/5

At 4 tools, the server is tightly scoped to the OSV advisory domain without unnecessary bloat. Each tool is essential for the core workflows of listing acceptable ecosystems, querying individual and batch packages, and fetching full advisory details.

Completeness5/5

The tool surface covers the fundamental lifecycle of vulnerability lookup: discover valid ecosystems, query for known vulnerabilities (both single and batch), and retrieve full advisory context. There are no obvious dead ends—an agent can chain queries to get complete remediation information.

Resources