OpenHermit exposes 32 tools with basic naming and minimal descriptions. Tool names follow verb_noun convention (memory_get, file_write, etc.), which is good. However, descriptions are extremely terse (10-50 chars), providing almost no context for LLM selection. Parameters lack type information in visible schemas, only parameter names and brief descriptions are shown. No output schemas documented. Error handling guidance absent. Security concerns: file_read/file_write/file_delete expose filesystem operations without path validation hints; exec tool allows arbitrary code execution with minimal safeguards described. Memory and session tools lack idempotency guarantees. Overall, definitions are skeletal, suitable for internal use but insufficient for production agent deployment.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and any prerequisites. Example: 'memory_get: Search agent memory for entries matching a query. Use this to retrieve past context before memory_add. Returns matching entries with IDs for memory_update.'
• Document input schemas with explicit types, required flags, and constraints. For file_read/file_write, add path validation rules (e.g., 'path must be within workspace root, no ../ traversal'). For exec, enumerate supported languages and timeout.
• Add output schemas for all tools. Specify returned fields, types, and pagination (if applicable). Example: memory_get returns [{id: string, content: string, created_at: ISO8601}].
• Implement confirmation/dry-run for destructive tools (file_delete, memory_delete, schedule_delete). Return a confirmation_token that must be passed to execute the deletion, preventing accidental data loss.
• Add error handling guidance. For each tool, document common failure modes and recovery steps. Example: 'file_read: If path not found, call file_list(parent_dir) to discover available files. If permission denied, check workspace configuration.'