OSV
OSV provides an open vulnerability database and API for querying vulnerabilities by package, version, commit, or vulnerability identifier.
Verdict
Common use cases
- Audit dependency manifests during pull request review
- Triage security alerts from CI pipeline failures
- Map CVE impact across microservice repos
- Validate patch coverage after dependency upgrades
- Research vulnerability timelines for incident reports
Integration
- Vendor
- OSV
- Category
- developer-tools
- Auth
- NONE
- Tools
- 5
- Composio slug
osv
Tools
- Determine Version
Experimentally rank probable versions of an OSS-Fuzz C/C++ library from relative source-file paths and base64-encoded MD5 hashes. Results may be empty or change because the API is experimental.
- Get Import Findings
Experimentally list OSV records from one exact import source that failed import-time quality checks; intended for OSV source maintainers and may return no records.
- Get Vulnerability
Return the complete OSV record for one case-sensitive vulnerability ID, including affected versions, ranges, severity, references, and aliases.
- Query Vulnerabilities
Find full OSV vulnerability records affecting one package, package version, package URL, or commit. Use next_cursor to continue a large result set.
- Query Vulnerabilities Batch
Check up to 1,000 packages, package versions, package URLs, or commits in one request and return position-matched compact vulnerability IDs. Continue unfinished items with their individual page tokens.
Setup
Setup guide
- 11. Open your Switchy workspace and navigate to Settings > Integrations. 2. Search for OSV in the MCP directory and click Connect. 3. No authentication is required—the connection activates immediately. 4. Create or open a Project where you want to check dependencies. 5. Type '@OSV query vulnerabilities for lodash version 4.17.19' in the chat to test the connection. 6. OSV returns a list of vulnerability IDs and details; if the package is clean, you'll see an empty result set. 7. For batch checks, prepare a list of package URLs or versions and ask '@OSV query vulnerabilities batch for these 50 dependencies' with the list pasted below. 8. Use the Get Vulnerability tool to fetch full CVE details when you need severity scores, patch links, or affected version ranges.
What teammates see: by default, memories from OSV are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
Check Single Package
@OSV query vulnerabilities for the npm package 'axios' version '0.21.1'
Batch Audit Dependencies
@OSV query vulnerabilities batch for these packages: lodash@4.17.20, express@4.17.1, react@17.0.1, django@3.1.0
Fetch Full CVE Details
@OSV get vulnerability details for CVE-2021-23337
Check Commit Hash
@OSV query vulnerabilities for commit hash 'a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0' in the Linux kernel repo
Identify Package Version
@OSV determine version for these C++ source files: src/core/lib.cpp (MD5: dGVzdGhhc2gxMjM0NTY=), include/header.h (MD5: YW5vdGhlcmhhc2g3ODkw)
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@OSV check if lodash version 4.17.15 has any known vulnerabilities and summarize the severity of each finding.
The OSV database returns 3 vulnerability records for lodash 4.17.15: CVE-2020-8203 (prototype pollution, CVSS 7.4 High), GHSA-p6mc-m468-83gw (command injection in template, CVSS 7.2 High), and GHSA-jf85-cpcp-j695 (ReDoS in template compiler, CVSS 5.3 Medium). All three have patches available in lodash 4.17.21 or later. The prototype pollution issue affects the defaultsDeep function when merging untrusted objects.
This example uses Query Vulnerabilities to check a specific package version. The MCP returns structured OSV records with CVSS scores, affected version ranges, and reference links. No authentication required, but results depend on what the community has reported to OSV — proprietary or internal vulnerabilities won't appear.
@OSV I'm reviewing dependencies in package.json — batch-check these 15 npm packages for vulnerabilities and flag any Critical or High severity issues.
Batch query complete for 15 packages. 4 packages returned vulnerability IDs: express@4.16.0 has 2 High-severity findings (CVE-2022-24999, GHSA-rv95-896h-c2vc), body-parser@1.18.3 has 1 High (CVE-2022-29167), minimist@1.2.5 has 1 Critical prototype pollution (CVE-2021-44906), and axios@0.21.1 has 1 High SSRF (CVE-2021-3749). The remaining 11 packages returned no known vulnerabilities. Full OSV records are available for each ID if you need remediation details.
This example uses Query Vulnerabilities Batch to check up to 1,000 packages in one request. The MCP returns compact vulnerability IDs matched by position to your input list. You'll need a follow-up call to Get Vulnerability for full remediation guidance. Batch queries are efficient but won't auto-resolve transitive dependencies — you must enumerate them yourself.
@OSV retrieve the full vulnerability record for GHSA-c2qf-rxjj-qqgw and explain what versions of the Go standard library are affected, plus the recommended fix.
GHSA-c2qf-rxjj-qqgw is a denial-of-service vulnerability in Go's archive/tar package. Affected versions: all Go releases before 1.20.6 and 1.19.11. The issue allows an attacker to craft a malicious tar archive with overlapping sparse-file regions, causing excessive memory allocation during extraction. The OSV record shows severity CVSS 7.5 (High) and references Go issue #60167. Recommended fix: upgrade to Go 1.20.6, 1.19.11, or later. No workaround exists for earlier versions.
This example uses Get Vulnerability to fetch a complete OSV record by ID. The MCP returns structured data including affected version ranges, severity scores, and upstream references. Useful when you already have a vulnerability ID from a scanner or batch query. The ID must be exact and case-sensitive — typos return nothing.
Use-case deep-dives
When OSV MCP fits your security-gate workflow
A 6-person backend team runs nightly dependency scans before merging to main. The OSV MCP is the right call here because it queries the Open Source Vulnerabilities database directly—no vendor lock-in, no rate-limit surprises, and the batch tool checks up to 1,000 packages in one shot. Your CI script feeds package URLs from your lockfile, the MCP returns CVE IDs, and you fail the build if any critical hits appear. The trade-off: OSV covers popular ecosystems (npm, PyPI, Maven, Go) well but lags on niche registries, so if you depend on obscure Rust crates or private mirrors, expect gaps. If your pipeline already parses SBOM or lockfiles and you want a free, API-first vulnerability check, this MCP slots in cleanly.
Why OSV MCP helps security teams move faster
A 3-person security team gets paged about a disclosed zero-day in a transitive dependency. They need the full CVE record—affected version ranges, CVSS score, upstream patches—without toggling between GitHub advisories and vendor dashboards. The OSV MCP's Get Vulnerability tool pulls the complete record by ID in one call, and Query Vulnerabilities finds every package in your stack that shares the same commit hash. This cuts triage time from 20 minutes of tab-hopping to under 2 minutes in a shared Switchy chat. The boundary: if your org mandates a commercial vuln-intel feed with SLAs and threat-actor attribution, OSV won't replace that—it's a community database, not a managed service. For fast, accurate lookups during live incidents, it's hard to beat.
When OSV MCP isn't the right tool
A 4-person support team fields questions about whether a customer's self-hosted deployment is vulnerable to a specific CVE. The OSV MCP can retrieve the vulnerability record, but it won't tell you if the customer's actual runtime version matches the affected range—that requires parsing their environment, not just querying a database. The MCP also doesn't surface remediation steps, rollback guides, or vendor-specific workarounds; it returns raw OSV JSON with version ranges and references. If your support workflow is 'look up CVE, then check internal runbooks', the MCP saves one browser tab. If you need end-to-end remediation guidance or integration with your ticketing system's custom fields, you'll still need a purpose-built vuln-management platform. Use OSV MCP for the lookup step, not the entire support flow.
Frequently asked
What does the OSV MCP do in Switchy?
It queries the Open Source Vulnerabilities database directly from your Switchy workspace. You can look up CVEs by package name, check if a specific version has known exploits, or scan entire dependency lists in one batch request. No API key required—OSV's database is public. Useful for security reviews, incident response, or auditing third-party libraries before you ship.
Do I need credentials to connect the OSV MCP?
No. OSV is a public database maintained by Google, so the MCP requires no authentication. Just enable it in Switchy and start querying. There's no OAuth flow, no API token to rotate, and no admin approval needed. Anyone on your team can add it to their workspace in under ten seconds.
Can the OSV MCP fix vulnerabilities or patch dependencies?
No. It only reads vulnerability data—it won't modify your code, update package.json, or apply patches. Think of it as a search engine for CVEs, not a remediation tool. After you find a vulnerability, you still need to manually upgrade the affected package or apply a workaround. Use it for discovery and triage, not automated fixes.
How is this different from running osv-scanner in CI?
The MCP runs interactively inside Switchy, so you can ask natural-language questions like "does lodash 4.17.19 have any CVEs?" and get instant answers. osv-scanner is a CLI tool you run in pipelines—great for blocking PRs, but slower for ad-hoc research. Use the MCP when you're investigating; use osv-scanner when you want automated enforcement.
Who on the team should use the OSV MCP?
Anyone doing security reviews, incident response, or dependency audits. Developers can check libraries before adding them to a project; security engineers can triage alerts from other scanners; engineering managers can spot patterns across multiple repos. Since it's read-only and requires no auth, there's no risk in giving the whole team access.