Two tools with reasonable descriptions but critical schema gaps. record_demo and capture_auth_state have clear, action-oriented names and descriptions (120-180 chars, within baseline 34-392 range). However, input schemas are not visible in the provided source code, only schema references (recordDemoInputSchema, captureAuthStateInputSchema) are imported but their actual definitions are not shown. Without seeing parameter types, descriptions, constraints, and output schemas, schema quality cannot be verified. Tool composition is sound (separate concerns), but lack of visible schema documentation is a hard blocker for production use.

• Provide full input schema definitions for both tools in the source. Include parameter types (string, number, boolean, array, object), descriptions (50-100 chars each), constraints (enums, min/max, regex patterns), and required vs optional flags.
• Document output schemas. Specify what fields record_demo returns (e.g., { file_path: string, duration_ms: number, success: boolean, error?: string }) and what capture_auth_state returns (e.g., { storage_state_path: string, success: boolean }).
• Add parameter descriptions to tool definitions. Explain what 'steps' is (array of action objects?), what 'auth' accepts (storage_state_path or inline cookies?), and what 'login_url' should be (full URL with protocol).
• Implement error recovery guidance. Update tool descriptions to state: 'If recording fails due to timeout, try increasing the step timeout. If auth capture fails, ensure the login page is accessible and JavaScript is enabled.'
• Add idempotency hints and confirmation patterns. For record_demo, document whether re-running with the same output_path overwrites or errors. For capture_auth_state, clarify whether closing the browser mid-auth cancels the operation.