13 tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error handling. Most tools lack descriptions of what they return, making it difficult for LLMs to plan downstream calls. Parameter descriptions are minimal (e.g., ashlr__bash has only 'Shell command to execute'). No evidence of error recovery guidance, confirmation patterns for destructive operations, or output field documentation. Naming is consistent (verb_noun prefix) but generic descriptions fail to explain WHEN to use each tool or what distinguishes similar tools (e.g., ashlr__edit vs ashlr__write vs ashlr__multi_edit).

• Document output schemas for all tools. Specify what fields are returned, their types, and which are required. Example: ashlr__read should return {content: string, size: number, encoding: string, path: string}.
• Expand tool descriptions to 100 - 200 characters explaining WHAT the tool does, WHEN to use it, and how it differs from similar tools. Example: 'ashlr__edit: Replace entire file content. Use for small files or complete rewrites. For multiple files, use ashlr__multi_edit. For line-by-line changes, use ashlr__bash with sed.'
• Add error handling guidance to each tool description. Example: 'ashlr__bash: Returns exit code and stderr. If exit code > 0, the command failed, check stderr for details. Retryable if stderr indicates transient error (e.g., network timeout).'
• Implement confirmation patterns for destructive tools (ashlr__bash, ashlr__edit, ashlr__write, ashlr__multi_edit). Support a dry_run parameter or require explicit confirmation before executing irreversible operations.
• Add parameter constraints and validation rules. Example: ashlr__bash should document timeout limits, allowed command patterns, and forbidden operations (e.g., no rm -rf /). Use enums for ashlr__genome_* keys if they are known.