Skip to main content
Glama

osv-advisory-mcp-server

by io.github.cyanheads

Osv Query Batch

osv_query_batch
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packagesYesPackages to audit. One entry per dependency. Positional: result[i] corresponds to packages[i].

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoPresent on all-clean or all-errors batches — the aggregate outcome for content-only clients.
resultsNoPer-package results, positionally matching the input array.
summaryNoAggregate statistics across the full batch.
effectiveQueryNoCompact scan summary (package and outcome counts), echoed on edge-case batches for content-only clients.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already carry readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavior beyond structured data: the positional correspondence between response entries and input tuples, and the batch size ceiling of 1000.

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?

Three sentences with zero filler. Purpose is front-loaded, then input format, then output/chaining behavior. Every sentence earns its place.

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?

An output schema exists, so return values need not be spelled out. The description covers everything an agent needs to call it: input shape, size limit, positional correspondence, and the CVE-alias chaining path for CVSS scoring.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by restating the tuple shape ({name, ecosystem, version}) and emphasizing the positional output mapping, which helps an agent interpret results. It does not duplicate parameter-level docs verbatim.

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?

States a specific verb+resource ('Query vulnerabilities for multiple packages in one call') and distinguishes itself as the primary batch tool for dependency audits, SBOM scanning, and lockfile triage. The batch-vs-single distinction against sibling osv_query_package is immediately clear.

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?

Gives clear usage context (dependency audits, SBOM scanning, lockfile triage) and a downstream chaining hint (to nist-nvd-mcp-server for CVSS scoring). It does not explicitly name osv_query_package as the single-package alternative, though the batch framing implies it.

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