Loading ToolBench
MCP server for web page capture and manipulation using Puppeteer
This server has severe definition quality issues across all four tools. Tool naming is generic and action-unclear (webpage_capture, webpage_save_to_html), descriptions are superficial without explaining when to use each tool or what it returns structurally, input schemas lack proper type annotations and parameter descriptions are minimal, and output schemas are completely undocumented. The run_cmd tool is a critical security liability with a DESTRUCTIVE risk marking yet no permission gates, rate limiting, or input sanitization guidance. Error handling is minimal, tools return raw subprocess errors without recovery guidance. The composition pattern is broken: run_cmd exposes arbitrary shell execution, which violates principle of least privilege and creates prompt injection vulnerabilities.
run a Linux command in the host. The command can be any valid Linux command. such as, run a command like `ls -l /home/user` to list the files in the directory "/home/user". or run a command like `cd /home/user && ls -l` to change directory to "/home/user" and list the files in the directory. or run a command like `curl https://www.example.com` to fetch the content of a webpage. or run a command like `cat /app/html/index.html` to read the content of a file. or run a command like `python -c "print(1+1)"` to run a Python script, it will return "2" or run a python command like `python -c "print('strawberry'.count('r'))"` to count the number of occurrences of the letter 'r' in the string "strawberry", it will return "3".
Get system information and return it as a JSON string.
capture the webpage and return the screen short path saved in the host
Save a webpage as an offline snapshot directory and return index.html path.
Critical Security Vulnerability: run_cmd exposes arbitrary shell execution with shell=True and no input sanitization. This is a prompt injection attack vector, an LLM can be tricked into passing malicious commands (e.g., 'rm -rf /', 'cat /etc/passwd', exfiltration commands). The tool lacks permission gates, rate limiting, command allowlisting, or audit logging.
Tool naming is vague and does not follow verb_noun convention. 'webpage_capture' and 'webpage_save_to_html' lack clarity on what distinguishes them (screenshot vs. HTML snapshot). LLMs cannot disambiguate without reading full descriptions. Best practice: 'screenshot_webpage' and 'save_webpage_snapshot'.
Descriptions are superficial and under 50 characters in several cases. 'capture the webpage and return the screen short path saved in the host' (60 chars) lacks context: When should LLM call this vs. save_webpage_snapshot? What is the return format? Is it a file path string? Can it fail? No recovery guidance provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Input schemas present but parameter descriptions are minimal or missing context. 'x' and 'y' are described only as 'x coordinate' with no explanation of coordinate system, valid range, or why these override URL rendering. Coordinates could be interpreted as viewport position, page position, or crop region, ambiguous names without type suffix (x_px, y_px_offset) invite wrong inputs.
Output schemas are completely undocumented. webpage_capture returns a string described as 'screen short path', but what format? Absolute path? Relative path? JSON? Is it guaranteed to exist? Can the path contain spaces? LLMs must guess, causing downstream failures when trying to read the file.
Error handling is minimal. Tools return raw subprocess stderr (e.g., 'Error capturing webpage: {e.stderr.strip()}') with no recovery guidance. An LLM seeing 'Error: no route to host' has no idea whether to retry, use a different URL, check network settings, or declare the URL invalid. Error messages must classify as retryable/user-fixable/fatal and suggest next steps.
The run_cmd tool violates composition principle, it does 'everything' (ls, curl, cat, python execution, cd). This is not one tool with one purpose; it is a shell gateway. Agents cannot plan properly when one tool can do any command. Split into dedicated tools: list_directory, fetch_url, read_file, execute_python_code.
The run_cmd tool lacks idempotency guarantees and confirmation gates for destructive operations. A command like 'rm -rf /app/data' is irreversible. Agents should not execute destructive commands without confirmation or dry-run support, but the tool provides neither.
system_info tool description ('Get system information and return it as a JSON string') is ambiguous about which fields are included, what the JSON structure looks like, or when to call it. No output schema documented. An LLM calling this tool has no way to know if it returns CPU count, memory, OS version, uptime, network info, or all of the above.
Parameter 'command' in run_cmd has a massive description (700+ chars with examples) embedded in the docstring. This is an anti-pattern, examples like 'ls -l /home/user' and 'python -c "print(1+1)"' will be reused literally by LLMs instead of adapting to context. Replace examples with formal constraints (regex pattern for allowed commands, allowlist of safe operations).