mcp-dependency-doctor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_PROJECT_ROOT | No | Absolute path to the project root used to confine project paths (realpath). Project tools accept `projectPath` relative to MCP_PROJECT_ROOT. Example: /absolute/path/to/your/project | . |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| dependency_inventoryA | Read declared dependencies and exact installed versions from npm lockfile v2/v3. No network. |
| dependency_auditA | Run read-only npm audit. Sends package versions to the configured npm registry. Never installs or fixes packages. |
| dependency_outdatedB | Read available updates using npm outdated. Requires network; never changes dependencies. |
| package_healthA | Inspect public npm package deprecation, release age, Node engine and peer requirements. Requirements are reported, not certified compatible. |
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 4 tools
The tools are mostly distinct: inventory reads lockfile data, audit checks vulnerabilities, outdated checks available updates, and package_health inspects package metadata. There is minor potential overlap between dependency_audit and package_health since both assess package quality/risk, but the descriptions make the boundary reasonably clear.
All names use snake_case and are descriptive noun-style tool names. Three use a dependency_ prefix while one uses package_health, which is a minor inconsistency but still readable and predictable.
Four tools is well-scoped for a dependency diagnostics server, with each operation covering a distinct diagnostic angle. There is no obvious bloat or missing basic operation.
The surface covers lockfile inventory, vulnerability audit, outdated packages, and package health metadata, which are core dependency-doctor workflows. Minor gaps exist around license compliance or dependency tree/duplicate analysis, but agents can work around them.