Loading ToolBench
Exposes TCPK's audit, recon, CVE matching, and exploit capability generation as Model Context Protocol tools over stdio (JSON-RPC 2.0). Read-only additive wrapper around the TCPK module.
TCPK is a specialized PowerShell-based security auditing server with 9 tools. While tool names follow the 'tcpk_' prefix convention and most tools have descriptions, significant quality gaps exist: (1) parameter descriptions are present but often generic and lack constraint details; (2) output schemas are NOT documented, no clear specification of what fields are returned or their types; (3) error handling is absent, no guidance on what to do if a tool fails; (4) parameter validation details are missing (e.g., tcpk_audit's 'processName' says 'cannot be a wildcard' but no pattern or constraint is declared); (5) several tools accept file paths without documented sanitization against path traversal attacks. Tool naming is consistent but generic (tcpk_* prefix doesn't convey action verbs like 'get_', 'list_', 'scan_'). Descriptions average ~100-150 chars, which is acceptable but lack the precision needed for LLM reasoning (no WHEN, WHY, or PREREQUISITE context). Per-tool scores range from 48-58; the average is 52.
Runs a full security audit on a target application, detecting misconfigurations, insecure patterns, and vulnerabilities. Writes findings to an output directory.
Matches detected components and versions against CVE databases to identify known vulnerabilities.
Decompiles a .NET assembly (DLL/EXE) and returns IL code. With a method parameter, returns IL for that specific method. Without a method, lists sink-bearing methods.
Generates proof-of-concept exploit code (Frida scripts, Python tools, etc.) for detected vulnerabilities. Requires explicit authorization and writes to the tool's work directory.
Retrieves audit findings from a completed audit output directory. Results are enriched with CVSS scores, CWE mappings, TASVS classifications, and verification hints.
Returns TCPK version and general server information.
NO OUTPUT SCHEMAS DOCUMENTED. None of the 9 tools declare what fields or types they return. LLMs cannot plan downstream tool calls or extract data without knowing the response structure. For example, tcpk_recon_profile returns 'a recon profile with structural analysis' but no field list is provided.
PARAMETER CONSTRAINTS NOT DECLARED. tcpk_audit.processName says 'cannot be a wildcard' but provides no regex pattern, format, or character restrictions. tcpk_cve_match.includePatched is a boolean but LLMs cannot infer what 'patched' means in this security context. Parameters lack enum constraints, length bounds, or validation rules.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Lists all .NET/managed modules found in a target application with summary information.
Scans a target application or file and returns a recon profile with structural analysis.
Extracts and returns interesting strings (URLs, credentials, identifiers) from a target application.
MISSING ERROR HANDLING GUIDANCE. No tool documents how failures are reported or what the LLM should do next. tcpk_decompile might fail if the DLL is corrupted or uses an unsupported .NET version, but no error classification (retryable, user-fixable, fatal) is provided. No recovery hints like 'Try tcpk_list_modules first to verify the assembly is valid.'
PATH TRAVERSAL RISK NOT MITIGATED. Tools accept 'target' (tcpk_recon_profile, tcpk_strings, tcpk_cve_match, tcpk_list_modules), 'dll' (tcpk_decompile), and 'outDir' (tcpk_audit, tcpk_get_findings, tcpk_generate_poc) as file paths. No description restricts these to safe directories or documents how the server prevents '../../../etc/passwd' style attacks. tcpk_audit mentions 'must be under the tool folder for write operations' but tcpk_decompile and read tools have no such guard documented.
DESTRUCTIVE/WRITE OPERATIONS NOT CLEARLY MARKED IN DESCRIPTIONS. tcpk_audit (WRITE risk), tcpk_generate_poc (DESTRUCTIVE risk), and tcpk_get_findings (writes to output directory) modify state, but only tcpk_generate_poc mentions 'Requires explicit authorization'. The descriptions do not clearly state that these tools have side effects, making it harder for LLMs to reason about reversibility.
GENERIC TOOL NAMING. Tool names like 'tcpk_info', 'tcpk_recon_profile' do not start with action verbs (get_, list_, scan_, analyze_). LLMs infer intent from verb_noun patterns. Renaming tcpk_recon_profile → tcpk_scan_application and tcpk_list_modules → tcpk_list_dotnet_modules would improve clarity.
MISSING DEPENDENCY HINTS. No tool description explains prerequisites or interdependencies. For example, tcpk_decompile requires a valid .NET assembly, but should mention 'Call tcpk_list_modules first to verify the target contains .NET assemblies.' tcpk_get_findings requires a prior tcpk_audit call, but this is not documented.
PAGINATION NOT ADDRESSED. tcpk_list_modules, tcpk_strings, and tcpk_cve_match may return large result sets (modules in a large binary, embedded strings, all CVEs for a component). No limit, offset, page, or cursor parameters are documented. Results could exhaust context windows.
tcpk_generate_poc REQUIRES EXPLICIT AUTHORIZATION BUT LACKS GUIDANCE. The 'authorized' boolean defaults to false, but no description explains what 'authorization' means (who grants it? under what conditions?). Is this a per-request token, a server config, or a policy?