Three tools with generally strong schemas and descriptions, but inconsistent depth. scorm_package has exceptional parameter documentation (30+ fields with detailed descriptions explaining milestones, success criteria, language tags, etc.); scorm_validate is minimal but appropriate for its single-purpose; scorm_selftest is a diagnostic with no parameters. All tools properly registered with input schemas visible in src/index.ts. Descriptions are clear and detailed (scorm_package ~800 chars, well above median of 194 chars). However, output schemas are NOT documented in the source code, tool responses are returned as structured objects but no schema is declared. Error handling is implicit (buildPackage likely returns errors, but no recovery guidance pattern visible). Tool names follow verb_noun pattern correctly (scorm_* prefix is clear namespace). Parameters use proper Zod types with constraints (min/max on numeric, enums for format/scorm_version, URL validation for base_url). No evident security issues, no credentials in parameters, file paths are validated via resolveOutputDir(). Risk annotations present (WRITE for scorm_package, READ_ONLY for validators). Composition is appropriate: three separate tools, each with single responsibility.

• Document output schemas for all three tools in the tool definitions. Add a 'result' field to the Zod schema describing the response structure: {zip_path: string, manifest_path: string, size_kb: number, ...}. Include this in the tool description or as a separate schema annotation.
• Expand scorm_validate and scorm_selftest descriptions to 100 - 150 characters. Explain what the tool returns and when an LLM should call it. E.g., scorm_validate: 'Validates a SCORM .zip against the spec and returns a detailed report. Use this to diagnose import failures or confirm a package is LMS-ready before deployment.'
• Add a 'Precedence' section to scorm_package description: 'If both html and input_path are provided, input_path takes precedence (files on disk are treated as the canonical source). Either html OR input_path is required; omitting both returns an error.'
• Enhance parameter descriptions with explicit error guidance. E.g., mastery_score: 'Pass threshold 0..1. Must be a decimal (e.g., 0.8 for 80%). Invalid values (>1, negative, non-numeric) will cause an error; the error message will specify the valid range and the value you provided.'
• Add structured error handling. Define error response format (e.g., {error: string, code: string, retryable: boolean}) and document common failures (missing title, invalid path, malformed HTML) with recovery steps. E.g., 'Path not found. Provide an absolute path to an existing file or directory.'
• Clarify batch mode behavior in scorm_package description. E.g., 'When batch=true, input_path must be a directory. Each subdirectory, .html file, or .zip in that directory becomes one package. A consolidated report lists all outputs and any per-course errors.'