Dependency Security MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level. | |
| MCP_SERVER_NAME | No | The name of the MCP server. | |
| SCAN_OUTPUT_ROOT | No | Root directory where scan output is written. | |
| SCAN_TIMEOUT_SECONDS | No | Scan timeout in seconds. | |
| ALLOWED_REPOSITORY_ROOTS | No | Comma-separated allowlist of repository roots. Requested repositories are resolved with Path.resolve() and must exist, be directories, and live below one configured root. | |
| OWASP_DEPENDENCY_CHECK_PATH | No | Path to the OWASP Dependency-Check executable. Defaults to `dependency-check` on PATH. | dependency-check |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_dependency_scanB | Start an OWASP Dependency-Check scan for an allowed repository path. |
| get_scan_statusC | Get status for a dependency vulnerability scan. |
| get_scan_reportB | Get the normalized vulnerability report for a completed scan. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool targets a distinct phase of the scan lifecycle: start a scan, poll its status, and retrieve the completed report. There is no functional overlap, and the descriptions clearly differentiate status polling from report retrieval.
All tool names follow a consistent snake_case verb_noun pattern (start_dependency_scan, get_scan_status, get_scan_report). The shared 'get_scan_' prefix for the two retrieval tools reinforces predictability.
Three tools are well-scoped for a focused dependency scanning service: initiate, monitor, and fetch results. The set contains no redundant or filler tools, and the count sits comfortably in the typical 3-15 range.
The core lifecycle (start → status → report) is fully covered, but there is no way to list existing scans or cancel a running scan. These are minor gaps that agents can work around by retaining scan IDs, but they limit multi-scan management.