dependency-audit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NPM_REGISTRY | No | Override for private/mirror registries. | https://registry.npmjs.org |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| audit_dependenciesA | Given the contents of a package.json, report every dependency's freshness against the npm registry: how far behind latest it is (patch/minor/major), how many versions behind, whether it's DEPRECATED, and its license. Reach for this when asked to 'update dependencies', 'check what's outdated', 'is anything deprecated', or before a dependency bump — it gives the agent real registry facts instead of guessing from stale training data. Read the repo's package.json and pass its full text as |
| check_packageA | Look up one npm package: its latest version, how far a given range/version is behind, deprecation status, and license. Use for a quick one-off check ('is X deprecated?', 'what's the latest Y?', 'how far behind is my Z?') without needing a whole package.json. |
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 2 tools
The two tools have clearly distinct scopes: audit_dependencies evaluates an entire package.json against the registry, while check_package focuses on a single package. There is no ambiguity about which tool to use for a given request.
Both tools follow the same verb_noun pattern with lowercase and underscores: 'audit_dependencies' and 'check_package'. The naming is consistent and predictable.
With only two tools, the server feels thin for a general dependency-audit purpose, but it does cover the two primary use cases: whole-project audit and single-package lookup. The count is borderline but not unreasonable for such a narrow domain.
The core auditing operations are covered: checking a full dependency set and checking an individual package. Minor gaps exist, such as lack of support for lockfiles or batch version comparisons, but these are workarounds and not severe.