Multi-platform AI chat bot with system management, file operations, browser automation, and scheduling capabilities. Supports Telegram, Slack, Discord, DingTalk, Lark, WhatsApp, and web UI.
lsbot exhibits significant quality gaps across naming, descriptions, and schema completeness. While 32 tools are registered with basic schemas, most lack actionable descriptions and parameter guidance. Critical issues: (1) Many descriptions are generic or too short (<20 chars), failing the LLM optimization bar. (2) Tool names lack clarity on preconditions and risk profiles (e.g., 'file_trash' has no input schema despite being destructive). (3) Parameters across all tools lack type constraints, validation hints, and format specifications. (4) Output schemas are not documented. (5) Error handling guidance is absent, no recovery hints or actionable error messages. This server is optimized for CLI/scripting, not LLM agents. Most tools score 25-45; a few with slightly better descriptions reach 50-55.
file_trash has no input schema and no description. A destructive tool with zero guidance violates security and usability principles. Cannot determine what parameters are required or what the tool actually does when called.
No parameter type constraints documented. Parameters like 'command', 'url', 'selector', 'timeout' lack enum declarations, format specifications, or validation hints (e.g., max timeout, allowed URL schemes). LLMs cannot infer valid ranges and will pass arbitrary values.
Descriptions across 20+ tools are generic, under 40 characters, or lack actionable guidance. Examples: 'Get an environment variable', 'List running processes', 'Get disk usage information'. These do not explain WHEN to use the tool, what it returns, or how to interpret results for LLM decision-making.
env_getenv_list
Recommendations
For each tool, add a 50-200 character description explaining: (1) What it does, (2) When to use it instead of similar tools, (3) What preconditions must be met. Current descriptions are 15-40 chars and too generic. Example: 'Read file_read: Retrieve the full text content of a file from disk. Use this before editing to verify current content. Fails if the file does not exist or lacks read permissions.'
Add enum constraints to all parameters with discrete valid values. Examples: (a) 'kind' in network_connections should be an enum: ['tcp', 'udp', 'tcp4', 'tcp6', 'udp4', 'udp6', 'all']. (b) 'timeout' should have a numeric range: min=1, max=300. (c) 'days' in file_list_old should specify min=1, max=365.
Document output schemas for all tools. For file_read, specify: { content: string, path: string, size_bytes: number }. For process_list, specify: { processes: [{ pid: number, name: string, status: string, memory_mb: number }], total_count: number }. This enables agents to extract fields for downstream calls.
Implement dry-run or confirmation for destructive tools. Add a 'confirm' parameter (default false) to file_trash, process_kill, cron_delete. If confirm=false, return a confirmation prompt. If confirm=true, execute. Example: 'Dry run: would delete file /tmp/old.log (2.5 MB). To confirm, call again with confirm=true.'
Add error classification and recovery hints to all tools. When a call fails, return JSON: { error: string, code: string, retryable: boolean, suggestion: string }. Example: { error: 'File not found: /home/user/missing.txt', code: 'ENOENT', retryable: false, suggestion: 'Use file_search() to locate the file, or check the path spelling.' }
No documented output schemas for any tool. LLMs cannot plan multi-step sequences or extract required fields (e.g., after search_users, what field contains the user_id?). Agents must guess field names, causing downstream tool call failures.
Destructive tools (file_trash, process_kill, cron_delete) have no dry-run, confirmation, or recovery guidance. Agents can delete critical processes or files without warning. No error classification (retryable vs. fatal) to guide recovery.
Parameters with implicit dependencies are undocumented. Example: cron_create accepts 'tool' and 'arguments', what if 'arguments' is an array vs. object? What fields must 'arguments' contain? LLMs cannot infer structure.
Tool names lack clarity on preconditions and side effects. 'browser_navigate' and 'browser_click' have no indication of whether they require an active browser session or what state they assume. 'shell_execute' does not clarify if it runs locally or remote.
No permission gates or scope declarations. Tools like 'shell_execute' and 'file_write' are unrestricted, any agent can run arbitrary commands or overwrite files. No audit trail or role-based access control.
Parameters do not accept natural identifiers (names, emails, usernames). All tools operate on system-level paths, PIDs, and opaque IDs. Agents cannot call 'kill process named nginx', they must ask for the PID, add a lookup step, and chain calls. Interface mismatches the chat data model.
calendar_today and calendar_list_events lack integration hints. No documentation of what calendar system they target (Google, Outlook, local iCal), authentication requirements, or available fields in returned events. Agents cannot determine if the tools are configured or what data to expect.
calendar_todaycalendar_list_events
For file_trash (currently empty schema), define input: { paths: [string], confirm: boolean }. Add description: 'Move one or more files to trash. Requires explicit confirmation via confirm=true. Returns list of moved paths and any errors per file.'
Reduce reliance on opaque IDs. Add 'process_name' parameter to process_kill (in addition to 'pid') so agents can call 'kill process nginx' without a lookup. Internally resolve name → PID with a partial match and confirmation if multiple matches exist.
Add per-tool permission hints in descriptions. Example for shell_execute: 'Requires system:shell_exec permission. Dangerous, no input sanitization. Agents can inject arbitrary commands. Log all invocations.'
Document browser state preconditions. Add a description note: 'Assumes an active browser session. Call browser_navigate() first if unsure. All browser_* tools operate on the same session and context.'
For cron_create, clarify the 'arguments' parameter. Document: 'object with tool-specific arguments, e.g., { path: "/home/user/file.txt" } for file_read. See the target tool definition for required/optional fields.'
Add pagination support to list tools. Example: process_list should accept 'limit' (1-1000, default 50) and 'offset' (default 0). Return { processes: [...], total: 1234, limit: 50, offset: 0 } so agents can iterate without overwhelming memory.
Implement rate limits and resource guards. Add notes in descriptions: 'This tool is rate-limited to 10 calls/minute. Exceeding the limit returns a 429 error with Retry-After header.' Prevents runaway agents from consuming system resources.