Two tools with detailed descriptions and comprehensive input schemas. book_skill has excellent parameter coverage (mode enum, file/MD5/query flexibility, dry_run, temperature controls) and clear mode-specific behavior documentation. skill_audit is simpler but well-defined. However, output schemas are not explicitly documented in the code, responses are JSON-stringified without formal schema declarations. Parameter descriptions are strong (72-194 chars average), but tool names lack action verbs (book_skill, skill_audit are noun-heavy). Error handling guidance is minimal, no recovery hints or categorization. No tool annotations (readOnlyHint/destructiveHint) despite skill_audit being read-only and book_skill having write modes.

• Rename tools to action-verb form: 'create_skill_from_book' (or 'extract_skill_from_book') and 'audit_skill_markdown'. This signals intent and helps LLMs disambiguate.
• Add explicit output schema documentation. Define SkillAuditOutput and BookSkillOutput types with field descriptions, then reference them in tool registration.
• Add tool annotations: skill_audit should have readOnlyHint=true; book_skill should have destructiveHint=true for create/enrich modes and idempotentHint=true for preview.
• Enhance error messages with recovery hints. E.g., 'Book not found (MD5: abc123). Try a search query instead: search_library("author name")' or 'Gemini API rate limit. Retry in 60s or reduce max_text_chars.'
• Add conditional parameter validation in the tool handler. If mode=enrich and !skill_path, return a clear error: 'skill_path is required for mode=enrich' instead of letting it fail downstream.