DepShield MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_dependencyA | Check a package for known vulnerabilities and verify it exists on the registry. MUST be called before installing any dependency. |
| audit_projectB | Scan a package.json or requirements.txt for all dependency vulnerabilities. Returns a full audit report. |
| find_safe_versionB | Find the newest version of a package with zero known vulnerabilities. |
| get_advisory_detailC | Get full details about a specific security advisory (CVE, GHSA, etc). |
| check_npm_healthB | Assess package health and trustworthiness: downloads, maintenance, license, deprecation status. Scored 0-100. |
| suggest_alternativeA | Find alternative packages when one is vulnerable, deprecated, or unmaintained. |
| deep_scanA | Scan a package's transitive dependency tree for vulnerabilities and suspicious patterns (newly added deps, typosquats, low-download packages). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| security_review | Guided full-project security review using all DepShield tools |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| status | DepShield server status and cache statistics |
TDQS
Scored across 7 tools
Tools are generally distinct with clear boundaries: audit_project targets manifest files, check_dependency is for pre-install validation, check_npm_health focuses on maintenance metrics, and deep_scan examines transitive dependencies. Minor overlap exists between check_dependency and check_npm_health (both examine single packages), but their purposes (security vs health) are different enough to guide selection.
Most tools follow a clear verb_noun pattern (audit_project, check_dependency, find_safe_version, get_advisory_detail, suggest_alternative). However, 'deep_scan' breaks the convention by using an adjective_noun structure rather than a verb-led name like 'scan_dependencies' or 'analyze_transitive_deps'. 'check_npm_health' is consistent but domain-specific (npm) while others are generic.
Seven tools is an ideal count for this domain. The set covers the full workflow: project scanning (audit_project), package vetting (check_dependency, check_npm_health, deep_scan), remediation (find_safe_version, suggest_alternative), and investigation (get_advisory_detail). No tool feels redundant or filler.
Strong coverage of the dependency security lifecycle including vulnerability detection, health assessment, transitive dependency analysis, and remediation strategies. Minor gaps include the lack of an 'apply_fix' or 'update_manifest' tool to automatically remediate findings, and no SBOM generation capability, but agents can work around these with the existing tools.