Dep Bouncer
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Optional. Port for the server to listen on. No environment variables are required. | |
| NITRO_LOG_LEVEL | No | Optional. Log level for the server. No environment variables are required. | |
| MCP_TRANSPORT_TYPE | No | Optional. Transport type for the server; one of `stdio` / `http` / `dual`. No environment variables are required. |
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
} |
| extensions | {
"io.modelcontextprotocol/app": {
"version": "2026-07-28"
},
"io.modelcontextprotocol/tasks": {
"version": "2026-07-28"
}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bouncer_check_packageA | Call this BEFORE |
| bouncer_check_upgradeA | Call this before bumping a dependency from one version to another. Returns the verdict on the new version plus what changed between the two (publisher, provenance, install scripts, dependencies). |
| bouncer_safe_versionA | Returns the newest version of a package (optionally within a semver range such as "^1.14.0") that passes every Dep Bouncer check, and which newer versions were skipped and why. Use it to pick what to install instead of a blocked release. |
| bouncer_review_install_scriptsA | npm 12 skips dependency install scripts until they are approved ( |
| bouncer_check_manifestA | Checks every dependency in a package.json at the version npm would install for its range today (the newest match), e.g. before running |
| bouncer_diff_releaseA | Raw evidence for humans: what changed between two versions of a package (publisher, provenance, install scripts, dependencies, files added/removed/changed, and risky code patterns new in this release). Use it to explain a REVIEW or BLOCK. |
| bouncer_replay_incidentA | Replays a real npm hijack through Dep Bouncer, as an agent would have met it 30 minutes after publication, before any advisory existed. Incidents: axios (2026), keyv (2026), chalk (2025), nx (2025), tinycolor (2025). The malicious versions were removed from npm, so the bad release is a clearly labelled reconstruction with benign stand-in code. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| safe_install | Instructions that make a coding agent vet every npm install with Dep Bouncer and act on the verdict. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Dep Bouncer policy | The signals Dep Bouncer runs, their weights, and how findings become ALLOW / REVIEW / BLOCK. |
| Replayable npm hijacks | Real npm hijacks Dep Bouncer can replay, with how long the free advisory database (OSV) took to list each one. |
| Health Checks & Pipeline Telemetry | Current health status, transform pipeline state, and sandbox metrics |
| Verdict Card | UI component for Verdict Card |
| Widget Examples | Provides metadata and examples for all registered UI widgets |
TDQS
Scored across 7 tools
Each tool has a distinct entry point (single new package, version bump, whole manifest, safe-version selection, install-script approval, raw diff, incident demo), and descriptions clarify when to use each. However, bouncer_check_package, bouncer_check_upgrade, bouncer_diff_release and bouncer_check_manifest all revolve around the same compare-a-release-to-its-history logic, so an agent may hesitate between them for a given situation.
All seven tools share the bouncer_ prefix and a consistent snake_case verb_noun pattern (check_package, check_upgrade, review_install_scripts, check_manifest, diff_release, replay_incident). bouncer_safe_version is the only slight deviation but remains readable and predictable.
Seven tools is well within the ideal 3-15 range and each one maps to a concrete workflow (vet a package, vet a bump, vet a manifest, pick a safe version, approve scripts, inspect a diff, demo an incident). No tool feels redundant or filler.
The surface covers the core dependency-vetting lifecycle: pre-install checks, upgrade checks, bulk manifest scanning, safe-version fallback, install-script approval review, diff evidence, and incident replay. Minor gaps exist around policy configuration/allowlisting and lockfile- or CI-level enforcement, but agents can work around these for the stated purpose.