Loading ToolBench
A Python MCP server providing tools for file operations, system control, scheduling, Telegram integration, YouTube downloads, and persistent data storage
Simple-MCP has 29 tools with significant definition quality gaps. While tool names follow verb_noun conventions (type_text, read_file, press_hotkey), many parameter descriptions are minimal or missing type constraints. Most critically: (1) Output schemas are undocumented, no tool declares what it returns beyond string responses, forcing LLMs to infer structure from examples. (2) Error handling is generic ('Error: {exception}') with no recovery guidance. (3) Parameter descriptions lack constraints (no enums for button types, no format specs for paths, no ranges for numeric delays). (4) Many parameters are underspecified: click_mouse accepts optional x/y but doesn't clarify what 'current position' means; schedule_telegram_message accepts multiple time formats without strict validation examples. (5) Tools like run_python_code and install_python_library are high-risk (IRREVERSIBLE/WRITE) with minimal guidance on safe usage. The server does provide descriptions for most tools (not blank), which prevents a lower floor, but quality is functional rather than LLM-optimized.
Click the mouse at the specified coordinates, or at the current position if not specified.
Create an empty file at the specified path.
Create a new folder (directory) at the specified path.
Delete a file.
Delete a key from the persistent info JSON file.
Echo back the input text.
Retrieve persistent info from disk.
No output schemas documented. All 29 tools return string responses but no schema explains structure (e.g., does read_file return {content: string} or {file: string, content: string}?). LLMs cannot parse responses or chain tools without documented output formats.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Install a Python library using pip and update requirements.txt.
List files and directories in the given path.
List the titles of all currently open windows.
List running processes.
Move a folder (directory) from src to dst.
Move the mouse cursor to the specified screen coordinates.
Press a combination of keys as a hotkey (e.g., ctrl, tab).
Read the contents of a file.
Receive updates (messages, etc.) sent to the Telegram bot. If any type of file is present in the update, download it to the download folder under telegram_downloads.
Rename or move a file.
Execute a snippet of Python code and return the output or error.
Schedule any registered function to be called at a specific time.
Schedule a recurring job using cron-like expressions.
Schedule a Telegram message to be sent at a specific time.
Send a message, audio, video, or document to a Telegram user or chat using the bot token from environment variables. Optionally, include metadata (such as performer, title, album for audio) if sending a file.
Switch focus to a window with the specified title.
Get basic system information.
Simulate typing the given text using the keyboard.
Update or add a key-value pair to the persistent info JSON file.
Write content to a file.
Download the audio of a YouTube video as an MP3 file.
Get basic information about a YouTube video.
Parameter constraints missing or underspecified. press_hotkey accepts arbitrary keys with no enum validation (should constrain to: ctrl, shift, alt, tab, enter, etc.). click_mouse button parameter should be enum [left, right, middle]. schedule_telegram_message accepts three different time formats (ISO, relative, natural) with no schema validation or examples showing exact format. Numeric parameters (interval, duration, x, y) lack min/max bounds.
Irreversible and high-risk tools (run_python_code, install_python_library, delete_file, delete_persistent_info_key) lack dry-run, confirmation, or explicit warning in descriptions. run_python_code is marked IRREVERSIBLE but description says only 'Execute a snippet' with no safety guidance. No error classification (retryable vs fatal) to guide agent recovery.
Error responses are raw exception strings with no recovery guidance. Example: 'Error typing text: {e}' tells the LLM nothing about why it failed or what to try next. No distinction between retryable errors (network timeout) and user-fixable errors (invalid file path). Pattern: pattern:recovery-guide recommends 'Invalid key: must be one of ctrl, shift, alt, try again' format.
File path handling lacks path traversal safeguards. read_file, write_file, delete_file, create_file all accept bare string paths with no validation. An agent could be tricked into reading /etc/passwd or writing to system directories. No description explains valid path boundaries (e.g., 'paths must be within project directory').
Scheduling tools (schedule_telegram_message, schedule_function_call, schedule_recurring_job) have weak parameter documentation. 'schedule_expression' for schedule_recurring_job mentions 'Cron-like' and 'Interval' but doesn't define strict syntax or provide validation. 'job_id' is optional with unclear auto-generation semantics. No error guidance for invalid schedules.
Telegram integration exposes chat_id parameter but doesn't explain it falls back to ADMIN_ID env var if omitted. Description says 'If not provided, uses ADMIN_ID from env' but LLMs don't understand environment variable fallbacks, this should be explicit in the tool description or parameters. Token/bot credentials are handled server-side (good), but the fallback logic is implicit.
Tool parameter descriptions are often generic placeholders. 'The path to the file', 'The message text to send', 'Optional path' are minimal. Baseline quality requires 50-200 char descriptions with context: WHAT, WHEN TO USE, constraints. Example: 'The file path (relative to project root, supports ./ prefix, max 255 chars)' is actionable; 'The path to the file' forces LLM guessing.
receive_telegram_updates marks as READ_ONLY but returns downloaded files to 'telegram_downloads' folder, a side effect that contradicts read-only classification. Response structure (update format, file download behavior) is undocumented, so LLMs don't know what data they'll receive or how to act on it.
Optional parameters lack clear semantics. click_mouse allows x/y to be optional (use current position), but 'current position' is undefined, what if the cursor hasn't been moved yet? move_mouse_to duration defaults to 0.0 (instant) but LLMs may expect gradual movement for visual feedback. No guidance on when to use defaults vs explicit values.