Skip to main content
Glama
4DA-Systems

@4da/mcp-server

Official
by 4DA-Systems
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Vulnerability scan

vulnerability_scan
Read-only

Scan npm/pnpm/yarn/bun, Cargo, Python, and Go lockfiles for OSV.dev vulnerabilities in installed and transitive dependencies, showing fix versions and pin locations; target one package on demand.

Instructions

Scan this project's lockfiles (npm/pnpm/yarn/bun, Cargo, Python, Go) for OSV.dev vulnerabilities in installed versions, transitives included, with fix versions and where each is pinned; package for one dep. Call when asked about security or CVEs. To vet a version first: dependency_check.

Input Schema

NameRequiredDescriptionDefault
packageNoOnly this package (any ecosystem, every installed copy, transitives included), with a `package_note` saying what the lockfiles hold for it. Use it to ask about one dependency instead of reading the whole report.
include_devNoInclude direct devDependencies (labelled `is_dev`, graded one level down). Default: true, as the 4DA app does; pass false for runtime dependencies only. Transitive dev/runtime scope may be unknown.
project_pathNoProject directory to scan. Default: current working directory.
force_refreshNoIgnore the OSV advisory cache and fetch fresh advisory data from OSV.dev (dependency versions are re-read on every lockfile change regardless). Default: false.
response_formatNoconcise (default): one row per vulnerable package version (worst severity, the version that fixes all its advisories, advisory count and first ids, where it is pinned), the 40 most severe and 25 recommendations, with counts of anything left out. detailed: one row per advisory with references, plus platform-inactive advisories, maintenance notices, install drift and resolution provenance.
severity_filterNoOnly show vulnerabilities whose presented severity is at or above this level.
include_test_fixturesNoAlso scan lockfiles under test-fixture directories (tests/, test/, fixtures/, testdata/, __fixtures__/, conformance/ ...). Default: false; they are counted under coverage.not_scanned instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv6.0.3
    • changedInput schema / properties / include_dev / description
      Previous value: -"Include known direct devDependencies. Transitive dev/runtime scope may be unknown. Default: false."New value: +"Include direct devDependencies (labelled `is_dev`, graded one level down). Default: true, as the 4DA app does; pass false for runtime dependencies only. Transitive dev/runtime scope may be unknown."
    • addedInput schema / properties / include_test_fixtures
      Added value: +{
+  "description": "Also scan lockfiles under test-fixture directories (tests/, test/, fixtures/, testdata/, __fixtures__/, conformance/ ...). Default: false; they are counted under coverage.not_scanned instead.",
+  "type": "boolean"
+}
  2. First observedv6.0.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network egress are covered. The description adds real context beyond them: it scans lockfiles rather than source, includes transitives, reports fix versions and pin locations, and queries OSV.dev for advisory data. It stops short of describing report size/limits, which is left to the schema.

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?

Front-loads the scan scope and ecosystems, then the trigger and the alternative in two short sentences. The opening clause is semicolon-dense but every clause (ecosystems, transitives, fix versions, pin locations) earns its place; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully summarizes what the report contains (fix versions, where each is pinned) and that transitives are included, complementing a fully documented 7-parameter schema. It omits mention of caching/refresh and report truncation behavior, but those are covered by the schema's own parameter docs.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already carries the semantics of all seven parameters. The description only echoes the `package` scoping behavior and alludes to fix/pin output; it adds no syntax, format, or default information the schema does not already provide. Baseline 3 applies.

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?

Names a specific verb (scan), resource (this project's lockfiles), the ecosystems covered (npm/pnpm/yarn/bun, Cargo, Python, Go), and the data source (OSV.dev). It also carves out the single-package variant (`package`) and names the sibling it is not (dependency_check), so an agent can separate it from alternatives without opening a schema.

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?

Gives an explicit trigger ("Call when asked about security or CVEs") and an explicit routing rule to an alternative with its condition ("To vet a version first: dependency_check"). It also directs single-dependency questions to the `package` parameter rather than a full report.

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