Skip to main content
Glama
fairquery

OSV Dependency Vulnerability Check MCP Server

by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check dependencies for known vulnerabilities (OSV.dev)

check_dependency_vulnerabilities
Read-onlyIdempotent

Check exact package versions or pasted manifests against OSV.dev to find known vulnerabilities, severity, and fixed versions before upgrading or shipping.

Instructions

WHAT: Check exact package versions, or a pasted manifest (package.json, package-lock.json v1-v3, requirements.txt with == pins, go.mod), against the OSV.dev vulnerability database (GHSA, PYSEC, GO, RUSTSEC, CVE aliases). WHEN TO USE: auditing a project or a list of dependencies before upgrading or shipping, or answering "is lodash 4.17.20 vulnerable and what should I upgrade to?". WHEN NOT TO USE: for the full record of an advisory ID you already have use get_vulnerability_details (free). Does not scan source code, containers or unpinned ranges (ranges produce VERSION_NOT_PINNED warnings). BEHAVIOR: read-only; runs the Fairquery Apify Actor fairquery/osv-dependency-vulnerability-check through the Apify API, which queries api.osv.dev. Requires APIFY_TOKEN. Typical run 5-60 s depending on package count. COST: paid (billed to your Apify account, pay-per-event): $0.00005 per run + $0.0009 per package row + $0.0028 per emitted vulnerability row; error/warning rows are free. Use minSeverity (e.g. "HIGH") and dedupeAliases=true to reduce rows and cost. Example: lodash + django (2 packages, 41 vulns) ~ $0.12. RETURNS: {count, items}. Every row has schema_version, type (package | vulnerability | error), source_url, checked_at. package rows: ecosystem, name, version, purl, vulnerable, vuln_count, vuln_ids, max_severity, max_cvss_score, fixed_versions, recommended_version (smallest version fixing all emitted vulns, or null). vulnerability rows: id, package_name, package_version, aliases, cve_ids, summary, details, severity, cvss_score, cvss_vector, cwe_ids, affected_ranges, fixed_versions, published, references, osv_url. error rows: code (INPUT_EMPTY, INVALID_PACKAGE, MANIFEST_UNDETECTED, MANIFEST_PARSE_FAILED, MAX_PACKAGES_EXCEEDED, OSV_QUERYBATCH_FAILED, OSV_VULN_FETCH_FAILED, or warnings VERSION_NOT_PINNED/VERSION_NOT_PINNABLE/RANGE_APPROXIMATED), message, retryable. EXAMPLE: {"packages":[{"ecosystem":"npm","name":"lodash","version":"4.17.20"}],"minSeverity":"HIGH"} -> 1 package row (vulnerable, recommended_version) + HIGH/CRITICAL vulnerability rows. Provide packages and/or manifestText (at least one).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packagesNoUp to 1000 exact package versions to check (optional if manifestText is given). Example: [{"ecosystem":"npm","name":"lodash","version":"4.17.20"}]
maxPackagesNoSafety cap on unique packages checked per run (1-10000, default 1000); extra packages produce a MAX_PACKAGES_EXCEEDED error row
minSeverityNoOnly emit vulnerabilities at or above this severity (CVSS v3 base score, else advisory label). Default ALL. Package rows are always emitted.
manifestTextNoOptional; up to 2,000,000 chars of raw file content of package.json, package-lock.json, requirements.txt or go.mod. Packages found are added to `packages`.
manifestTypeNoFormat of manifestText (default "auto" = detect from content)
dedupeAliasesNoEmit one row per real vulnerability when OSV lists it under several IDs, preferring the GHSA record (default true)
includeDevDependenciesNoInclude devDependencies from package.json / dev packages from package-lock.json (default true)
includeUnknownSeverityNoWith minSeverity set, still emit vulnerabilities whose severity is unknown (default true)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of rows returned
itemsYesResult rows; each has a "type" field (data rows or machine-readable "error" rows)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv1.1.1
    • addedInput schema / properties / dedupeAliases / description
      Added value: +"Emit one row per real vulnerability when OSV lists it under several IDs, preferring the GHSA record (default true)"
    • addedInput schema / properties / includeDevDependencies / description
      Added value: +"Include devDependencies from package.json / dev packages from package-lock.json (default true)"
    • addedInput schema / properties / includeUnknownSeverity / description
      Added value: +"With minSeverity set, still emit vulnerabilities whose severity is unknown (default true)"
    • changedInput schema / properties / manifestText / description
      Previous value: -"Raw package.json, package-lock.json, requirements.txt (== pins) or go.mod content"New value: +"Optional; up to 2,000,000 chars of raw file content of package.json, package-lock.json, requirements.txt or go.mod. Packages found are added to `packages`."
    • addedInput schema / properties / manifestText / maxLength
      Added value: +2000000
    • addedInput schema / properties / manifestType / description
      Added value: +"Format of manifestText (default \"auto\" = detect from content)"
    • addedInput schema / properties / maxPackages / description
      Added value: +"Safety cap on unique packages checked per run (1-10000, default 1000); extra packages produce a MAX_PACKAGES_EXCEEDED error row"
    • changedInput schema / properties / minSeverity / description
      Previous value: -"Only return vulnerabilities at or above this severity (default ALL)"New value: +"Only emit vulnerabilities at or above this severity (CVSS v3 base score, else advisory label). Default ALL. Package rows are always emitted."
    • changedInput schema / properties / packages / description
      Previous value: -"Exact package versions to check"New value: +"Up to 1000 exact package versions to check (optional if manifestText is given). Example: [{\"ecosystem\":\"npm\",\"name\":\"lodash\",\"version\":\"4.17.20\"}]"
    • changedInput schema / properties / packages / items / properties / ecosystem / description
      Previous value: -"OSV ecosystem, e.g. npm, PyPI, Go, Maven"New value: +"OSV ecosystem name: npm, PyPI, Go, Maven, crates.io, RubyGems, NuGet, Packagist, Pub, Hex (aliases like pip/cargo/gem are accepted)"
    • addedInput schema / properties / packages / items / properties / name / description
      Added value: +"Package name as published, e.g. \"lodash\", \"django\", \"github.com/gin-gonic/gin\", \"org.apache.logging.log4j:log4j-core\""
    • addedInput schema / properties / packages / items / properties / version / description
      Added value: +"Exact version, e.g. \"4.17.20\" (no ranges like ^4.0.0)"
    • addedInput schema / properties / packages / maxItems
      Added value: +1000
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "description": "Number of rows returned",
+      "type": "integer"
+    },
+    "items": {
+      "description": "Result rows; each has a \"type\" field (data rows or machine-readable \"error\" rows)",
+      "items": {
+        "additionalProperties": {},
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "items"
+  ],
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds substantial extra context: the backing Apify actor and upstream api.osv.dev, the required APIFY_TOKEN, typical 5-60s runtime, the pay-per-event cost model with per-row pricing, and a concrete cost example. These are behavioral facts annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Long but deliberately structured under WHAT/WHEN TO USE/WHEN NOT TO USE/BEHAVIOR/COST/RETURNS/EXAMPLE labels and front-loaded. The RETURNS section restates fields already carried by the output schema, which is the one mildly expendable block.

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 paid, externally-dependent, 8-parameter tool this is complete: inputs, auth, runtime, pricing, error/warning codes, and an example are all present, and return-value detail is a bonus rather than a gap given an output schema exists.

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 the baseline is 3, but the description adds real decision-relevant meaning: minSeverity and dedupeAliases are framed as cost-reduction levers, versions must be pinned (ranges yield VERSION_NOT_PINNED warnings), and a worked example shows packages plus minSeverity in use.

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 (check exact package versions or a manifest against OSV.dev), names the advisories sources, and explicitly distinguishes itself from the sibling get_vulnerability_details by function.

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?

Has explicit WHEN TO USE (auditing before upgrading/shipping) and WHEN NOT TO USE sections that name the alternative tool get_vulnerability_details and the condition selecting it, plus scoping exclusions (no source/container scanning, no unpinned ranges).

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

Deploy Server

Other Tools