Skip to main content
Glama
depwire

depwire

Official
by depwire
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

security_scan

Scan a codebase for vulnerabilities like CVEs, injection, hardcoded secrets, and auth flaws, then rank findings by severity and elevate risks reachable from MCP tools or HTTP routes.

Instructions

Scan the codebase for security vulnerabilities using deterministic checks + graph-aware severity scoring. No API key required.

Checks: dependency CVEs, shell injection, hardcoded secrets, path traversal, auth bypass, input validation, information disclosure, cryptography weaknesses, frontend XSS, architecture-level risks.

Graph-aware severity: vulnerabilities reachable from MCP tools or HTTP routes are automatically elevated. A medium shell injection reachable from connect_repo becomes Critical.

Returns ranked findings (Critical → Low) with attack scenarios and suggested fixes. Use --target for single-file scan.

Input Schema

NameRequiredDescriptionDefault
targetNoRelative file path to scan. Omit to scan entire repo.
classesNoVulnerability classes to check. Omit for all.
graphAwareNoEnable graph-aware severity elevation (recommended). Default: true.
dependencyAuditNoRun dependency CVE and supply-chain checks. Default: true; set false to skip audit requests.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.28.2
    • addedInput schema / properties / dependencyAudit
      Added value: +{
+  "description": "Run dependency CVE and supply-chain checks. Default: true; set false to skip audit requests.",
+  "type": "boolean"
+}
  2. Addedv1.19.0
  3. Removedv1.8.4
  4. Addedv1.4.0
  5. Removedv1.3.0
  6. Addedv1.1.2

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the graph-aware elevation rule with a concrete example ('a medium shell injection reachable from connect_repo becomes Critical'), the deterministic-check basis, and the ranked Critical→Low output with attack scenarios and fixes. It does not state read-only guarantees, runtime cost, or whether it modifies any project state.

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?

Front-loaded with the core purpose and mechanism, then organized into labelled sections for checks and severity behavior. Slightly verbose in the check enumeration, and the '--target' CLI flag notation is a minor mismatch with the actual `target` parameter name.

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?

No output schema exists, and the description compensates by describing the ranked findings, severity ordering, attack scenarios, and suggested fixes returned. Combined with the full check-class list and severity model, an agent has enough to invoke it correctly; only return-format details and safety/permission posture are left unstated.

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 schema already documents all four parameters, making 3 the baseline. The description reinforces graph-aware scoring and dependency auditing conceptually and hints at single-file scanning via '--target', but adds no syntax or format detail 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?

States a specific verb and resource ('Scan the codebase for security vulnerabilities') plus the mechanism (deterministic checks + graph-aware severity scoring). None of the siblings perform security scanning, so it is trivially distinguishable from connect_repo, impact_analysis, verify_change, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives operational guidance ('No API key required', 'Use --target for single-file scan') but never states when to choose this over siblings such as verify_change or impact_analysis, nor any when-not-to-use conditions. Usage is implied rather than directed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools