A multi-platform AI agent server with MCP (Model Context Protocol) support, enabling scheduled task execution, file management, shell commands, system monitoring, and cross-platform messaging
lsbot defines 25 tools with basic schemas and descriptions, but exhibits systematic quality gaps typical of a community-grade server. Most tools have descriptions (positive), but many descriptions are cursory (under 50 chars), parameter documentation is sparse or missing entirely, and output schemas are never documented. The schema definitions present are minimal, parameters have types and a few have descriptions, but most lack detail, constraints, or format guidance. No tool shows error handling that guides recovery or self-correction. Tools follow a clear naming convention (verb_noun) which is good, but composition raises concerns: shell_execute and process_kill are destructive and high-risk, yet have no confirmation patterns, dry-run modes, or detailed permission documentation. The cron_* tools reference an 'arguments' parameter (object type) with no schema or validation guidance, LLMs will struggle to construct valid payloads. Overall, the server is functional but lacks the rigor expected of production agent tooling.
Output schemas are never documented. No tool declares what fields it returns, forcing LLMs to guess the structure and call downstream tools blind. This violates the response-shaper pattern and prevents proper tool chaining.
Destructive tools (shell_execute, process_kill, file_write, cron_create, cron_delete) lack confirmation patterns, dry-run modes, or explicit error guidance. An LLM can invoke 'process_kill pid=1' or 'shell_execute command=rm -rf /' with no safeguards. No mention of permission gates or audit trails.
Add a 'returns' section to every tool definition documenting output schema: { field_name: type, ... }. For example, file_info should return { path, size, mode, modified_time, is_directory }. This enables LLMs to extract the right data and chain tools correctly.
Implement a confirmation pattern for destructive tools. Add a 'dry_run' parameter (boolean, default false) to shell_execute, process_kill, file_write, and cron_delete. When dry_run=true, describe what would happen without executing. Require explicit confirmation for irreversible operations.
Expand parameter descriptions to 50 - 150 characters. Instead of 'Name of the executable', write 'The executable name or path (e.g., python, /usr/bin/python3). Will search $PATH if not a full path.' Include valid ranges, examples, and constraints.
Add per-tool error handling guidance. For network_ping, document: 'If the host is unreachable, a timeout error will be returned. Try network_dns_lookup to verify the hostname resolves first.' For shell_execute, document exit codes and stderr redirection.
Formalize the 'arguments' object schema in cron_create. Define which fields are required, their types, and how they map to the target tool. Add validation examples: { tool: 'send_message', arguments: { channel: 'alerts', text: '...' } }.
Add strict validation to shell_execute timeout parameter: 1 - 3600 seconds (1 hour max) to prevent DoS. Document the default (30s), unit (seconds), and behavior if timeout is exceeded (SIGTERM after N seconds, then SIGKILL after grace period).
cron_create accepts an 'arguments' parameter typed as 'object' with no schema, constraints, or validation guidance. LLMs cannot infer what fields this object should contain, and invalid payloads will fail silently or produce cryptic errors.
Most parameter descriptions are absent or generic ('Name of the executable', 'Path to the file'). Descriptions under 50 chars lack guidance on format, range, constraints, or when to use the tool. LLMs cannot disambiguate tools or validate inputs based on these descriptions.
shell_execute accepts a 'timeout' parameter with no guidance on valid range, unit, or default semantics. Can LLMs pass 0? 999999? What happens if timeout < 0? No error handling guidance either.
No error classification or recovery guidance across any tool. Errors are returned as-is with no hint whether they are retryable, user-fixable, or fatal. An LLM getting 'connection refused' has no guidance on what to do next.
file_search and file_list do not document pagination, limits, or result capping. If a glob pattern matches 10,000 files, does the tool return all of them? This risks context window exhaustion and degrades LLM reasoning.
calendar_list_events accepts a 'days' parameter but does not describe what calendar source it reads from (system calendar? third-party API?). No mention of whether the tool requires authentication or how conflicts are resolved.
network_connections 'kind' parameter is described with a list of enum values inline ('tcp, udp, tcp4, tcp6, udp4, udp6, all'), but parameter constraints are not formally declared. LLMs may try invalid values like 'TCP' or 'tcp/ip'.
cron_create description references 'arguments' as a passthrough to the tool, but does not explain what schema that object must conform to. The code snippet shows special handling of 'message' and 'prompt' fields, but this is undocumented in the tool definition.
cron_create
Document pagination and result limits for file_list and file_search. Cap results at 100 items by default, add a 'limit' parameter (1 - 1000), and return a 'total_count' or 'has_more' indicator. Example: 'First 100 matches; use limit=100 and iterate to retrieve more.'
Specify which parameters accept human-friendly names vs. opaque IDs. For process_kill, document: 'Accepts process ID (pid). To kill by name, first call process_list with filter, then extract the pid from the result.' This guides multi-step patterns.
Declare tool permissions and risk levels explicitly. Create metadata: { risk: IRREVERSIBLE, requires: ['system.process.kill'], audit: true } for destructive tools. This enables permission-gated agent configurations and clear audit logging.
Add idempotency guarantees. Document which tools are idempotent (safe to retry) and which are not. For example, file_write is idempotent if it overwrites (safe to retry), but cron_create is not (retrying twice creates two jobs). Provide deduplication guidance.
Enrich error messages with recovery hints. Instead of 'Host unreachable', return 'Host unreachable. Try: (1) network_dns_lookup to verify hostname, (2) network_ping with a longer timeout, or (3) check firewall rules.' This guides agent self-correction.
Document dependencies between tools. For calendar_list_events, clarify: 'Returns events from the local system calendar (via iCalendar or OS API). Does not integrate with Google Calendar, Outlook, or other third-party calendars. First call calendar_today to verify access.' This prevents tool misuse.