Distributed Risk

Check dependencies against the vulnerability record

check_dependencies

Read-onlyIdempotent

Which of these package versions have a known vulnerability. Give packages directly (ecosystem, name, version), or paste a lockfile or SBOM as manifest and it is read for you: package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, Pipfile.lock, go.mod, go.sum, Cargo.lock, Gemfile.lock, composer.lock, packages.lock.json, gradle.lockfile, cyclonedx, spdx, purls. Each version is checked against OSV.dev, which aggregates GitHub's reviewed advisories, the Go and PyPI databases, RustSec and OpenSSF's malicious-package reports across npm, PyPI, Go, Maven, crates.io, NuGet, RubyGems, Packagist and more. Every hit comes back with its severity, the CVEs it is known by, the versions that fix it, whether CISA lists it as exploited with the federal due date, and FIRST's EPSS estimate. Exploited packages come first, then malicious packages, then severity. A version with no hit is a version no advisory in those databases covers; that is not a statement that it is safe. Only resolved versions are read: a file of ranges (package.json, Pipfile, pom.xml) cannot be checked, so pass the lockfile beside it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_dependencies"
  }
}

Input Schema

Name	Required	Description
`limit`	No	How many affected packages to return. The counts cover all of them.
`filename`	No	The manifest's filename, when you have it. Without it the format is read from the content.
`kev_only`	No	true: only advisories CISA lists as exploited.
`manifest`	No	The contents of a lockfile or SBOM. Use this or packages.
`packages`	No	The packages to check, as installed. Use this or manifest.
`severity_min`	No	Only this severity and above. Malicious packages and anything CISA lists as exploited are always returned.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no output schema, the description carries the full burden and delivers: it names the data sources (OSV.dev aggregating GitHub, Go, PyPI, RustSec, OpenSSF malicious-package reports), enumerates the return fields (severity, CVE aliases, fixing versions, CISA KEV status with federal due date, EPSS), and specifies result ordering (exploited, then malicious, then severity). The caveat that 'no hit is not a statement that it is safe' is exactly the kind of interpretive context annotations cannot provide.

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?

Three sentences, front-loaded with the core question before the input instructions and the data-source detail. The long enumeration of ecosystems and advisory sources is informative but dense; it could be trimmed without losing much, which keeps it just short of a 5.

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 6-parameter, no-output-schema tool, the description supplies everything an agent needs: input modes, format support, source coverage, return contents, ordering, and the safety-interpretation caveat. Nothing material is left for the caller to guess.

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; the description adds real value by listing the accepted lockfile/SBOM formats (npm, pnpm, yarn, Poetry, Go, Cargo, CycloneDX, SPDX, purls, etc.) that the schema only gestures at with 'lockfile or SBOM'. It also reinforces the resolved-version constraint on packages. It doesn't address limit, kev_only, or severity_min specifics beyond what the schema already says.

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?

Opens with a specific verb framing ('Which of these package versions have a known vulnerability') that names the resource (package versions) and the check performed. It is clearly distinguishable from siblings like get_cve or search_kev, which retrieve advisories rather than evaluating a supplied dependency set.

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 explicit input-mode guidance: pass packages directly, or paste a lockfile/SBOM as manifest. It also states a clear when-not ('a file of ranges ... cannot be checked, so pass the lockfile beside it'), which is the main failure mode. It does not, however, route the agent to sibling tools (e.g., get_cve for a single CVE), so 'alternatives' is not covered.

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

All Distributed Risk tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?