ProjectDocumenter has 4 tools with basic verb-noun naming (generate-, document-, update-, assess-). All tools have descriptions (10-100 chars baseline met). However, input schemas are visible but minimal: only 1-2 parameters per tool with basic string/boolean types. No output schemas documented. Parameter descriptions are present but terse (e.g., 'Absolute path to the project directory'). No error handling guidance, no enums, no validation rules in descriptions. Tools lack idempotency hints, confirmation patterns for destructive operations (write risk), and chaining metadata. Composition is reasonable (4 distinct tools), but descriptions do not explain WHEN to use each tool vs. alternatives or what downstream tools need.

• Add explicit output schemas to all tools. E.g., generate-project-md should return {success: boolean, filePath: string, fileCount: number, message: string}. Document in tool description.
• Enhance parameter descriptions with format/constraint rules. E.g., 'projectPath: Absolute path to an existing, readable project directory (e.g., /home/user/my-project). Must be a directory, not a file.'
• Add idempotency hints to tool descriptions. E.g., 'generate-project-md: Idempotent. Safe to call multiple times; overwrites project.md if it exists.'
• Implement recovery guidance in error messages. E.g., 'Error: Cannot access directory /path/to/project. Verify the path exists, is readable, and is a directory (not a file).'
• Clarify tool composition in descriptions. E.g., 'document-project: Generates both project.md and README.md in one call. Use generate-project-md alone if you only need project.md.'