DepHealth 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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| audit_projectA | Scan a project's dependency manifests (package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml) and report known vulnerabilities from the OSV.dev database. Use before deploying, reviewing, or adopting a codebase. |
| check_packageA | Assess one package before adding or upgrading it: known vulnerabilities (OSV.dev) plus health signals (deps.dev) — latest version, license, release recency, deprecation. Returns a verdict: ok, caution, or avoid. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| security_review | Guided dependency security review of a project. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| supported_ecosystems | Supported ecosystems and the manifest files scanned for each. |
TDQS
Scored across 2 tools
Each tool has a clearly distinct purpose: audit_project scans entire project manifests for vulnerabilities, while check_package assesses a single package before adding/upgrading. No overlap in functionality.
Both tool names follow the consistent verb_noun pattern using snake_case (audit_project, check_package), making them predictable and easy to understand.
With only 2 tools, the server is minimal but well-scoped for dependency health auditing. While additional tools could be added, the current set covers the core use cases.
The tools cover the primary needs: scanning a project and checking a single package. Missing operations like updating dependencies or listing all vulnerabilities are minor gaps that agents can work around.