Tuls provides 12 tools with basic naming and descriptions, but critical gaps undermine production readiness. Tool names follow verb_noun convention (read_file, write_file, list_directory, delete_file, fetch, memory_set/get/delete, shell_execute, skill_execute, agent_spawn, agent_send_message), which is positive. However, descriptions are minimal (10-50 chars) and lack actionable context for LLM selection. Parameters have type definitions but descriptions are sparse or missing entirely. No output schemas are documented. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. Security-critical tools (shell_execute, delete_file, write_file) lack permission gates or audit trail documentation. The agent_spawn and agent_send_message tools are underspecified, no documentation of what 'instructions' format is expected, what 'tools' array contains, or how agent lifecycle is managed.

• Add output schemas for all tools. Document return types, field names, and structure. Example: read_file should return {content: string, encoding: string, size_bytes: number}.
• Expand parameter descriptions to 50-100 chars with constraints. For shell_execute: 'Shell command to execute (bash/sh). Max 10000 chars. Timeout 100-300000 ms. Env vars as JSON object.'
• Implement confirmation pattern for delete_file and shell_execute. Add a 'dry_run' boolean parameter or require explicit confirmation before destructive operations.
• Document error responses with recovery guidance. Example: 'File not found at /path/to/file. Check path spelling or use list_directory() to explore available files.'
• Add permission/scope documentation. Specify what access each tool requires (e.g., shell_execute requires 'exec:shell', delete_file requires 'write:filesystem'). Gate tools behind permission checks.

Inferred effective spec: 2026-07-28+.

• Current-spec patterns present: Multi Round-Trip Requests