Provides secure command execution capabilities in a containerized Kali Linux environment with background job management, interactsh integration for out-of-band interaction detection, and service token management for reconnaissance and intelligence gathering.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has significant definition quality gaps that limit LLM usability. While all 10 tools are explicitly registered with schemas and basic descriptions, the descriptions are often generic or incomplete (many under 100 chars), parameter descriptions are sparse or missing entirely, output schemas are not documented, and error handling guidance is absent. The tool names follow verb_noun conventions (good), but descriptions fail to answer 'when to use this instead of similar tools' or 'what does it return'. For example, 'run_kali_command' is clear, but 'get_job_status' lacks detail on the return structure. None of the tools have documented output schemas, making it impossible for agents to chain results. The 'get_service_tokens' tool is particularly risky, it exposes API tokens without explaining secret injection patterns or permission gates. Overall, this reads like a functional but developer-centric tool set, not one optimized for LLM-driven discovery and safe composition.
Output schemas are never documented. LLMs cannot infer what fields tools return, breaking downstream tool composition and forcing agents to guess result structure.
Parameter descriptions are missing or extremely brief (under 20 chars) for many tools. 'timeout' in run_kali_command lacks explanation of the 60-second background job threshold. 'output_file' in start_interactsh gives no guidance on absolute vs relative paths.
Add structured output schema documentation for every tool. Example for run_kali_command: 'Returns {type: 'immediate'|'background', stdout: string, stderr: string, exit_code: int, job_id?: string}'. This enables agents to chain results.
Expand tool descriptions to 50-150 chars, answering: What does this do? When should I use it instead of similar tools? What does it return? Example: 'run_kali_command: Execute a bash/shell command in the Kali environment. Use for reconnaissance, exploitation, and post-exploitation tasks. Returns stdout, stderr, exit code; long tasks (>60s timeout) run as background jobs and return a job_id for polling.'
Add detailed parameter descriptions with format/constraint hints. For timeout: 'Timeout in seconds (1-36000). Queries <60s run synchronously; >60s become background jobs with polling via get_job_status. Default: 300.'
Document the job status state machine. What values can status take (running, completed, failed, cancelled)? What is returned in payload? Example: 'get_job_status returns {job_id, status: running|completed|failed|cancelled, stdout?, stderr?, exit_code?}'.
Add permission checks and audit logging. Describe which user/agent roles can invoke each tool. Example: 'run_kali_command requires pentester or admin role. All executions logged with timestamp, user, command, exit code.'
Add error recovery guidance. Example for run_kali_command: 'If exit_code != 0, stderr contains failure reason. Common: exit_code=127 (command not found, is it installed in Kali?), exit_code=1 (syntax error, check command). Use list_background_jobs to diagnose hung processes.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 1 points across a rubric change (v1 → v2)
52/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
52
<=2025-11-25
v2
2026-03-09
D
51
-
v1
run_kali_commanddestructivesource verified77/100
Execute a command in the Kali Linux environment. Automatically runs as a background job if timeout > 60 seconds, otherwise runs synchronously.
start_interactshwritesource verified60/100
Start an interactsh-client worker in the background to monitor for out-of-band interactions. Returns generated payload URLs.
Tool descriptions are generic and do not explain when to use each tool or differentiate from similar ones. 'List all background jobs and their current status' lacks context: what status values are possible? Should I call this before cancel_job? When does status_watching_and_polling become necessary vs get_job_status?
get_service_tokens exposes sensitive API credentials without explanation of secret handling. Description should state: 'Server-injected tokens are returned; never log or pass to untrusted components.' Also lacks permission gate, who should call this tool?
No error handling guidance. Tools do not document how to recover from common failures (invalid job_id, timeout, file not found, permission denied). Error responses likely return raw JSON or exceptions without actionable guidance.
Destructive and long-running operations (run_kali_command marked DESTRUCTIVE) lack confirmation steps or dry-run modes. An agent could accidentally delete files or disable systems without user approval.
Pagination and result limiting are missing. run_kali_command can return arbitrary-length output; list_background_jobs may return thousands of jobs. No limit, offset, or cursor parameters documented.
Tool names 'start_interactsh', 'get_interactsh_status', 'poll_interactsh', 'stop_interactsh' reference an internal implementation detail (interactsh). For clarity, consider renaming to 'start_oob_listener', 'get_listener_status', 'poll_listener_interactions', 'stop_listener' to match agent intent.
Implement pagination for list_background_jobs: add limit (default 20, max 100) and offset parameters. Return {jobs: [...], total_count, has_more}.
Add dry_run mode to run_kali_command: 'If dry_run=true, show what would be executed but don't run it. Useful for agents to preview reconnaissance commands before execution.'
Rename interactsh tools for clarity: start_oob_listener, poll_listener_interactions, get_listener_status, stop_oob_listener. Document the state machine: inactive → listening → received_interactions → stopped.
For get_service_tokens, add a note: 'Returns server-injected secrets. Never log these or pass to external APIs. Use with read-only recognition tools only. Requires 'read:secrets' permission.'
Add idempotency hints where applicable. cancel_job should state: 'Canceling an already-stopped job returns success (idempotent). Useful for cleanup in error recovery.'
Document required cwd parameter for run_kali_command. Is it an absolute path? Can it be a symlink? Relative to what base? Example: 'cwd: Absolute path in the Kali container (e.g. /tmp/reconnaissance). Use get_workspace_info to discover available directories.'
Add mutual-exclusion documentation. If start_interactsh and a running reconnaissance command conflict, state: 'Only one interactsh listener can run at a time. Stop existing listener with stop_interactsh before starting a new one.'
Return contextual error messages with recovery hints. Instead of 'Job not found', return 'Job abc123 not found (expired after 24h). Use list_background_jobs to see active jobs. Or check archived_job_logs for history.'
Add examples of chaining. Document that run_kali_command returns job_id → pass to get_job_status → when complete, results available in stdout. This teaches agents the intended flow.