Loading ToolBench
Security Analysis Server for Claude Code - integrates 15+ SAST tools (Opengrep, Bandit, Bearer, Semgrep, TruffleHog, Trivy, etc.) via MCP protocol for AI-powered security analysis
The SAST-MCP server exposes 24 tools across security scanning domains (SAST, dependency checks, secrets, malware, IaC). While tool names follow a consistent `<tool>_scan` pattern with action verbs, the implementation exhibits systematic gaps in schema completeness, parameter validation, and error guidance. Most tools have generic or incomplete descriptions. Input schemas visible in the provided code show only 1-2 parameters per tool with minimal constraint documentation. Output schemas are not documented. Error handling provides no recovery guidance. The server delegates to external binaries (opengrep, bandit, semgrep, etc.) but does not validate their output or provide structured error classification. No parameter descriptions mention constraints (paths, file types, enums), inviting invalid input from LLMs. Tools operate at the "execute external command and return output" level, lacking the composition and chaining support that production agents require.
Execute Bandit security analysis for Python code to find common security issues
Execute Bearer security analysis for detecting secrets and sensitive data exposure in code
Execute Brakeman security scanner for Ruby on Rails applications to identify security vulnerabilities
Execute Checkov Infrastructure-as-Code security scanner to identify misconfigurations in Terraform, CloudFormation, Kubernetes, and other IaC templates
Execute ClamAV malware scanner to detect malicious code and known malware signatures in files
Execute OWASP Dependency-Check to identify known vulnerabilities in application dependencies
Execute ESLint with security plugins for JavaScript/TypeScript code quality and security analysis
22 of 24 tools have minimal input schemas with only 1 - 2 parameters, most without type constraints, enum declarations, or validation rules. E.g., 'bearer_scan' accepts only 'target' and 'scanner' with no enum for scanner type, no validation range, no guidance on which scanners are valid.
No output schemas documented for any tool. LLMs cannot predict what fields to expect (e.g., does opengrep_scan return findings[], vulnerabilities, or raw JSON from the CLI?). Agents cannot plan downstream composition or extract the right data.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-11 | F | 23 | - | v1 |
Retrieve server statistics including active scans, CPU/memory usage, and scan history
Execute Gitleaks secret scanning to detect secrets in git repositories and history
Execute Gosec security scanner for Go source code to identify security vulnerabilities
Execute Graudit source code audit scanner to identify security issues and potential vulnerabilities in source code
Execute Hadolint Docker linter to identify best practice violations and potential security issues in Dockerfiles
Execute NodeJSScan security scanner for Node.js applications to identify security vulnerabilities and code quality issues
Execute npm audit dependency vulnerability scanner for Node.js projects to identify known security vulnerabilities in dependencies
Execute Opengrep static analysis for finding security vulnerabilities and code issues. Opengrep supports 30+ languages including Python, JavaScript, Java, Go, Ruby, PHP, etc. This tool now runs with async/await for better performance and uses maximum accuracy by default.
Execute OSV-Scanner to identify known vulnerabilities in open source dependencies using the OSV database
Execute pip-audit to audit Python packages for known vulnerabilities
Execute Safety dependency vulnerability scanner for Python packages to identify known security vulnerabilities
Execute Semgrep static analysis for multi-language security vulnerability detection
Check the health status of the SAST Tools API Server
Execute Snyk vulnerability scanner for open source dependencies and container images
Execute tfsec security scanner for Terraform infrastructure-as-code to identify security misconfigurations
Execute Trivy vulnerability scanner for container images, filesystems, and Git repositories
Execute TruffleHog secret scanning to detect exposed secrets and credentials in code repositories
Most parameter descriptions are generic or truncated (35 - 50 chars). E.g., bearer_scan 'scanner' param: description is 'Bearer scanner type to use', does not enumerate valid types, does not explain what 'type' means (secret detection? data flow?), does not guide the LLM on when to use which scanner.
No error handling or recovery guidance. If a scan binary is missing, invocation fails, or output is malformed, the tool returns a raw error with no hint for the LLM on what to do next (install the tool, check permissions, retry, use an alternative scanner).
All scanning tools are write operations (they spawn external processes, potentially modify filesystem, write output files) but descriptions do not explicitly state this. The 'opengrep_scan' description mentions 'output_file' param but does not warn that results are written to disk. Agents cannot reason about idempotency or side effects.
Parameter 'target' appears in all scanning tools but is never validated for path traversal, symlink attacks, or other injection vectors. LLMs could be tricked into scanning sensitive directories or files outside the intended scope. No documentation of which paths are allowed.
No tool composition support. A common use case is 'scan with opengrep AND bandit AND safety' (polyglot scan), but tools do not return IDs or references that enable chaining or correlation. An agent would have to invoke 3 tools in parallel, then manually correlate findings, no mechanism for grouping or deduplication across scanners.
Tool names like 'opengrep_scan', 'bearer_scan', 'bandit_scan' are repetitive and generic. They do not distinguish between a SAST scan (code analysis) and a dependency scan or secrets scan. Better names: 'scan_code_opengrep', 'scan_dependencies_safety', 'scan_secrets_bearer', or group tools by category (e.g., 'scan_code_vulnerabilities', 'scan_secrets', 'scan_dependencies').
'opengrep_scan' accepts 'config' parameter with enum values (auto, p/security-audit, p/owasp-top-ten, etc.) but other scanning tools (semgrep_scan, bandit_scan, etc.) do not expose equivalent configuration. This creates an asymmetry where some scanners are configurable and others are not, forcing agents to guess or request clarification.