Two well-named, focused tools with strong descriptions (180+ chars each) and complete input schemas. Both tools are read-only, reducing risk. Schemas use proper Zod validation with min/max constraints on string parameters. Descriptions clearly state WHEN to use each tool and what it returns. However, output schemas are not documented in the visible code, only input schemas are explicit. Tool annotations are referenced but not visible in the provided source. Error handling is mentioned (NotFoundError imported) but recovery guidance is not visible in the tool definitions themselves.

• Document output schemas for both tools. For check_package, specify: { exists: boolean, latest_version: string, deprecated: boolean, advisory_count: number, suspicious: boolean, reason?: string }. For get_migration_delta, specify: { breaking_changes: Array<{symbol, type, before, after, source_url}>, security_advisories: Array<{id, severity, url}> }.
• Add error recovery guidance to descriptions. E.g., check_package: 'If suspicious=true, do not install, ask the user to verify the package name.' get_migration_delta: 'If version not found, suggest calling check_package to verify the version exists.'
• Verify and document tool annotations in the visible code. Ensure CHECK_PACKAGE_ANNOTATIONS and GET_MIGRATION_DELTA_ANNOTATIONS are exported and set readOnlyHint=true (both are read-only per the Risk field).
• Consider adding a 'reason' or 'details' field to error responses. When check_package detects a typosquat, return not just suspicious=true but also why (e.g., 'no repository URL, placeholder version 0.0.1, single release').
• Add pagination or result limits to get_migration_delta if it can return large lists of breaking changes. Specify max items returned and whether pagination is supported.