Six tools with basic schemas and descriptions, but significant gaps in parameter documentation, error handling, and LLM-optimized guidance. Tool names are action-oriented (readFile, writeFile, listFiles, runCommand, searchMemory, getProjectContext), but descriptions lack context on WHEN to use each tool and what downstream tools expect. Parameters have types but most lack detailed descriptions explaining constraints, formats, or dependencies. No output schemas documented. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. The runCommand tool accepts a whitelist but provides no guidance on what happens on failure or how to interpret command output.

• Document output schemas for all tools. Example: readFile should return {content: string, encoding: string, size: number}. listFiles should return {files: [{name, path, size, extension}], total: number}. This enables LLMs to chain tools and extract required fields.
• Expand parameter descriptions with format, constraints, and examples. E.g., 'path: Relative path from project root (e.g., force-app/main/default/classes/MyClass.cls). Must exist for readFile; parent directories auto-created for writeFile.' Add min/max length for 'query' in searchMemory.
• Add error handling guidance to runCommand. Document: 'Returns {exitCode, stdout, stderr}. Non-zero exitCode indicates failure. Common errors: command not whitelisted (exit 1), command not found (exit 127). Retry is safe for transient errors (network timeouts); fatal for syntax errors.'
• Clarify getProjectContext purpose and output. Describe what 'context' includes (project structure, metadata, dependencies, etc.). Return a structured object with clear fields so agents know what data is available without trial-and-error.
• Add composition hints in descriptions. E.g., readFile: 'Use listFiles first to discover available files.' searchMemory: 'Stores results from previous tool calls; useful after runCommand or readFile to avoid re-reading.' This guides multi-step planning.