Loading ToolBench
MCP server for adversarial security research — 6-phase pipeline from profile to disclosure
Hyperdope has 10 tools with good naming (verb-noun structure like hd_scan, hd_profile) and detailed descriptions (100-250 chars each), but suffers from critical schema and composition gaps. Input schemas are present for all tools but lack proper JSON Schema structure in the code, Zod definitions use generic z.object() with minimal type constraints. Parameters lack descriptions in some cases (context params are minimally described). Output schemas are completely undocumented, no definition of what each phase returns, forcing LLMs to guess at the structure. The tool set itself is problematic: the 6-phase pipeline (profile→audit→confirm→assess→draft_ghsa→disclose) is inherently sequential and stateful, yet the MCP server design treats them as independent tools. This violates the composition principle: agents should be able to call tools in any order, but these tools have hard dependencies (profile must run before audit; audit before confirm). The 'context' parameter is a workaround for passing state between phases, not a proper solution. hd_verify and hd_run are meta-tools that don't fit the normal tool interface. Overall, descriptions are LLM-optimized but schemas are weak, and tool design reflects implementation architecture rather than agent usability.
Phase 4: CVSS v3.1 scoring with per-metric chain-of-thought; score verified mathematically from the vector string — LLM cannot hallucinate the number
Phase 2: 5-step adversarial vulnerability hunt — entry point inventory, source→sink tracing, control gap analysis, assumption violation, chain candidates. OWASP Top 10, SANS 25, LLM Top 10.
Hyperdope CI/CD scanner — scans a directory for vulnerable dependencies, hardcoded secrets, and suspicious npm lifecycle hooks. Exits with code 1 if any finding meets or exceeds the severity threshold (default: high)
Phase 3: Generate up to 3 PoCs ordered by exploitability, with reliability rating and detection likelihood
Phase 6: Coordinated disclosure package — executive brief, full technical advisory with IoCs and remediation, vendor notification email with 90-day timeline table
Output schemas completely undocumented. No tool response structure is defined, what fields do profile, audit, confirm return? LLMs cannot extract the right data or plan downstream calls without documented output shapes.
Context parameter (z.record(z.unknown())) has no type constraints or description of expected structure. What schema does 'context from hd_profile' follow? What keys must context contain to use it in hd_audit? Agents cannot validate or construct context objects.
Tools enforce sequential pipeline execution (profile→audit→confirm→assess) via undocumented context dependencies, not via proper schemas or error handling. An agent calling hd_confirm without running hd_profile first will fail silently or with cryptic error. This should be validated explicitly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
Phase 5: GitHub Security Advisory draft (GHSA schema), remediation priority P1/P2/P3, disclosure readiness checklist
Phase 1: Map the target attack surface — STRIDE threat model, data flows, trust boundaries, parsers, deserialization, supply chain, auth flows, LLM surfaces
Run the full 6-phase audit pipeline (or a single phase) directly from the terminal — no MCP client required
Phase 0: Scan dependencies against OSV.dev CVE database — no API key required. Supports npm (package-lock.json / package.json), Python (requirements.txt / poetry.lock / Pipfile.lock), Go (go.mod), Rust (Cargo.lock). Also detects hardcoded secrets in config files and suspicious npm lifecycle hooks (postinstall / preinstall / prepare). Returns SBOM-lite.
Verification phase: Determine whether reported vulnerabilities are PATCHED, STILL_VULNERABLE, PARTIAL_FIX, or CANNOT_VERIFY in a patched target. Uses 4-question methodology: root cause identification → change analysis → variant bypass check → sibling site audit. Run after hd_assess (or hd_confirm) when a patch is available.
hd_run is a meta-tool that encapsulates the entire pipeline. Agents should compose individual phase tools, not invoke a hidden runner. This violates the 'each tool does exactly one thing' principle and makes observability, error recovery, and partial runs harder.
No error classification or recovery guidance. What if hd_profile fails partway through? Is it retryable? Should the agent skip to hd_audit? The error responses (visible in code) are raw JSON objects without actionable next steps.
Input schemas use z.record(z.unknown()) for context instead of a properly typed schema. This fails the 'parameters lack type definitions' rule, schema score cannot exceed 30 for affected tools.