Skip to main content
Glama

osv-advisory-mcp-server

by io.github.cyanheads

Osv Query Package

osv_query_package
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesPackage name as it appears in the ecosystem (e.g. "express", "requests", "serde"). Case-sensitive.
versionYesPackage version to check (e.g. "4.17.1", "3.1.4", "1.0.0"). Must be an exact version string, not a range.
ecosystemYesEcosystem 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

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
vulnsNoVulnerabilities matching this package version. An empty array means no known vulnerabilities ONLY when truncated is false.
noticeNoPresent on the clean path — confirms no known vulnerabilities for the queried package.
queryMetaNoQuery parameters as submitted.
truncatedNoTrue 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.
effectiveQueryNoThe package@version (ecosystem) tuple as queried, echoed for content-only clients.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already convey readOnlyHint and idempotentHint, indicating a safe, repeatable operation. The description adds value by disclosing that an invalid ecosystem returns an error (not empty results) and by outlining the return structure (severity, CVEs, version ranges, first safe version). This exceeds the annotation-only picture without contradicting it.

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, no fluff. The primary purpose and return value are front-loaded, followed by a concise usage tip. Every word earns its place, and the structure is instantly scannable.

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 single-version query tool with three required parameters, a full input schema, and an output schema, the description covers the essential aspects: purpose, return content, error behavior, and a necessary prerequisite. 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?

The input schema provides 100% coverage with detailed descriptions for each parameter (exact version strings, ecosystem examples, case-sensitivity). The description adds no parameter-specific information beyond what the schema already states. Baseline 3 is appropriate since the schema handles the heavy lifting.

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 clearly states the verb (Query), resource (known vulnerabilities for a single package version), and scope (across any supported ecosystem). It also enumerates the returned data, making it distinct from sibling tools like osv_query_batch (batch query) and osv_get_vulnerability (specific vulnerability lookup). The wording leaves no ambiguity about what the tool does.

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

Usage Guidelines4/5

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

It provides explicit guidance to validate the ecosystem string via osv_list_ecosystems and warns about case-sensitivity and error behavior. However, it does not explicitly contrast with osv_query_batch or osv_get_vulnerability, leaving the agent to infer when to choose this tool over those siblings. Still, the context is clear enough for most use cases.

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