Skip to main content
Glama

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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "results",
      +      "summary"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / error
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "Present when the call failed. Absent on success.",
      +  "properties": {
      +    "code": {
      +      "description": "JSON-RPC error code for this failure.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "data": {
      +      "additionalProperties": {},
      +      "properties": {
      +        "reason": {
      +          "description": "Machine-readable failure mode.",
      +          "type": "string"
      +        },
      +        "recovery": {
      +          "additionalProperties": {},
      +          "description": "Actionable next step for the caller.",
      +          "properties": {
      +            "hint": {
      +              "type": "string"
      +            }
      +          },
      +          "required": [
      +            "hint"
      +          ],
      +          "type": "object"
      +        },
      +        "retryable": {
      +          "description": "Whether retrying may succeed.",
      +          "type": "boolean"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "message": {
      +      "description": "Human-readable description of what went wrong.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "code",
      +    "message"
      +  ],
      +  "type": "object"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "results",
      -  "summary"
      -]
  2. Changed6 schema fields changed
    • addedInput schema / properties / packages / items / properties / ecosystem / minLength
      Added value: +1
    • addedInput schema / properties / packages / items / properties / ecosystem / pattern
      Added value: +"\\S"
    • addedInput schema / properties / packages / items / properties / name / minLength
      Added value: +1
    • addedInput schema / properties / packages / items / properties / name / pattern
      Added value: +"\\S"
    • addedInput schema / properties / packages / items / properties / version / minLength
      Added value: +1
    • addedInput schema / properties / packages / items / properties / version / pattern
      Added value: +"\\S"
  3. Changed5 schema fields changed
    • addedOutput schema / properties / results / items / properties / truncated
      Added value: +{
      +  "description": "True when OSV paginated beyond the fetch cap for this package — its result may be INCOMPLETE. A truncated row with no vulnerabilities is NOT confirmed clean.",
      +  "type": "boolean"
      +}
    • changedOutput schema / properties / results / items / required
      Previous value: -[
      -  "name",
      -  "ecosystem",
      -  "version",
      -  "vulnerable",
      -  "error",
      -  "vulnCount",
      -  "vulns"
      -]New value: +[
      +  "name",
      +  "ecosystem",
      +  "version",
      +  "vulnerable",
      +  "truncated",
      +  "error",
      +  "vulnCount",
      +  "vulns"
      +]
    • changedOutput schema / properties / summary / properties / cleanCount / description
      Previous value: -"Packages with no vulnerabilities."New value: +"Packages confirmed clean — no vulnerabilities, no error, and not truncated."
    • addedOutput schema / properties / summary / properties / truncatedCount
      Added value: +{
      +  "description": "Packages whose OSV results were truncated (may be incomplete). A truncated package with no findings is NOT counted as clean.",
      +  "type": "number"
      +}
    • changedOutput schema / properties / summary / required
      Previous value: -[
      -  "totalPackages",
      -  "vulnerableCount",
      -  "cleanCount",
      -  "errorCount",
      -  "totalVulns",
      -  "worstSeverity"
      -]New value: +[
      +  "totalPackages",
      +  "vulnerableCount",
      +  "cleanCount",
      +  "truncatedCount",
      +  "errorCount",
      +  "totalVulns",
      +  "worstSeverity"
      +]
  4. Changed2 schema fields changed
    • addedOutput schema / properties / effectiveQuery
      Added value: +{
      +  "description": "Compact scan summary (package and outcome counts), echoed on edge-case batches for content-only clients.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / notice
      Added value: +{
      +  "description": "Present on all-clean or all-errors batches — the aggregate outcome for content-only clients.",
      +  "type": "string"
      +}
  5. Changed2 schema fields changed
    • removedInput schema / properties / canvas_id
      Removed value: -{
      -  "description": "Reuse an existing DataCanvas table token to append results. Omit to create a new canvas. Only relevant when package count >= 200.",
      -  "type": "string"
      -}
    • removedOutput schema / properties / canvas_id
      Removed value: -{
      -  "description": "DataCanvas table token. Present when the package count is >= 200 or a canvas_id was provided. Use to run SQL queries across the full result set via the canvas tools.",
      -  "type": "string"
      -}
  6. First observed

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.

Try in Browser

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.