Loading ToolBench
Node.js MCP for authorized frontend security recon and deep web JS reverse analysis
taco-mcp exhibits significant definition quality gaps. While all 12 tools have descriptions and input schemas are present in code, the schemas lack proper JSON Schema formalization in the tool definitions. Tool names use inconsistent patterns (taco_* vs reverse_*) without clear action verbs. Descriptions are present but often vague (e.g., 'Analyzes JavaScript source code' without stating WHEN to use it or what makes it distinct from similar tools). Parameter descriptions exist but lack format constraints, ranges, or validation guidance. Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (generic try-catch returning e.message). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Security-focused domain (reverse engineering, secret scanning) but no permission gates or audit trail guidance.
Analyzes JavaScript source code to extract API contracts, security leads, mining roadmap, and fast verification plans for reverse engineering
Collects all sources from a URL and performs reverse engineering analysis including asset inventory and API contract extraction
Extracts API contracts from JavaScript source code including endpoint URLs, methods, parameters, and authentication dependencies
Builds a fast verification plan and extracts security leads from collected sources for rapid exploitation testing
Generates an exploitation mining roadmap from reverse engineering analysis results
Returns a JavaScript runtime hook script for intercepting and logging fetch, XHR, WebSocket, storage, and form submission events in the browser
Identifies security leads and fast verification plans from JavaScript source code for exploitation roadmap
Output schemas not documented. LLMs cannot predict response structure (e.g., taco_map_stack returns 'technologies', 'summary', 'security_headers' but this is not declared in tool definition). Agents cannot plan downstream tool calls or extract fields reliably.
Parameter descriptions lack format constraints and validation rules. E.g., 'mode' param accepts 'auto', 'static', or 'browser' but this is not stated in the parameter description, only in the tool description. LLMs cannot validate input before calling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Scans JavaScript source code for security leaks, secrets, credentials, API endpoints, sensitive routes, and cryptographic patterns with severity and confidence scoring
Collects and analyzes technology stack signals from a URL, including security headers, cookies, meta tags, runtime globals, and confidence-scored technology fingerprints
Collects all assets and source code from a URL including scripts, stylesheets, inline scripts, and source maps with fetch methods and error tracking
Fingerprints HTTP response headers, server information, favicon hash, and security headers to identify technologies and misconfigurations
Performs vulnerability audit on frontend source code, building a fast verification plan and identifying security leads
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all 12 tools being read-only. Agents cannot determine which tools are safe to retry or compose without side effects.
Inconsistent naming patterns. Tools use both 'taco_*' (action unclear) and 'reverse_*' (noun-first, not verb-first). Names like 'taco_map_stack' and 'reverse_mining_roadmap' do not start with clear action verbs (get_, analyze_, extract_). LLMs struggle to infer intent from names alone.
Error handling is generic (catch-all try-catch returning e.message). No recovery guidance, error classification, or actionable next steps. E.g., if URL validation fails, the agent receives 'Invalid URL' with no hint to try a different URL or check network policy.