Both tools have strong, specific descriptions (100+ chars each) that explain the security use case and distinguish them from similar tools. However, critical gaps undermine the score: input schemas are not visible in the provided source code, parameter descriptions are missing, and output schemas are undocumented. The tool names are clear action-oriented verbs ('maintainer-change-check', 'subdomains'), but without visible schema definitions and parameter documentation, these tools cannot reliably guide LLM selection or parameter construction. The descriptions alone cannot compensate for missing formal constraints and output structure documentation.

• Add explicit JSON Schema definitions for both tools. For maintainer-change-check: document that 'ecosystem' is an enum with value 'npm', and 'package' is a string with length constraints (e.g., 1-214 chars per npm spec). For subdomains: document that 'domain' is a string matching FQDN pattern and explain whether wildcards are supported.
• Write parameter descriptions that guide LLM input. E.g., 'ecosystem: Package ecosystem. Currently supports npm only.' and 'package: The npm package name (e.g., lodash, express). Case-sensitive.' For subdomains: 'domain: The domain to scan for subdomains (e.g., example.com). Wildcard domains not supported.'
• Document output schemas. Specify what fields are returned (e.g., maintainer-change-check returns {is_new_publisher: boolean, publisher_name: string, last_known_publisher: string, dormancy_days: number}). Include field descriptions so LLMs know what to extract.
• Add error handling guidance. E.g., 'If package not found, try searching npm registry directly. If no subdomains found, the domain may not have public CT logs.' This enables LLMs to suggest next steps instead of failing.
• Rename tools to verb-noun form: 'check-maintainer-change' or 'detect-maintainer-takeover' for the first; 'discover-subdomains' or 'list-subdomains' for the second. This makes the action explicit and helps LLMs parse intent from the name alone.