Substrate provides 43 tools across filesystem, text, system, process, subprocess, network, and launch domains. All tools have descriptions (10-50 chars, mostly terse) and visible input schemas with typed parameters. Naming follows verb_noun convention (fs.read, process.list, launch.up). However, descriptions are uniformly brief (avg ~25 chars vs. baseline 194 chars), lack WHEN/WHY context, and omit dependency hints. Parameter descriptions exist but are minimal (avg ~15 chars vs. baseline 72 chars). Output schemas are not documented in the source. Error handling is not visible in tool definitions. Destructive tools (fs.remove, process.signal, launch.down) lack confirmation patterns or dry-run support. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) detected. Risk classifications are present in metadata but not surfaced to LLMs.

• Expand tool descriptions to 50 - 200 chars. Include WHAT the tool does, WHEN to use it (vs. similar tools), and what it returns. E.g., 'Get file metadata (size, permissions, timestamps). Use this to check if a file exists or inspect its properties before reading. Returns structured metadata object.'
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to all tool definitions. Mark fs.remove, process.signal, launch.down as destructiveHint=true so agents apply extra caution.
• Document output schemas for all tools. Specify field names, types, and whether results are paginated. E.g., subprocess.spawn should document that it returns {job_id: string, status: string, ...}.
• Implement confirmation patterns for destructive operations. Add a dry_run parameter to fs.remove and launch.down, or require explicit confirmation via a separate confirm_* tool.
• Enhance parameter descriptions with format/constraint details. E.g., 'path: Absolute or relative filesystem path (string, max 4096 chars). Relative paths are resolved from cwd.' instead of just 'Path to file'.