Single tool with basic schema and description. Tool naming is clear (get_whois). Input schema is visible with proper type definition, but lacks parameter description depth. Description is present but generic (31 chars). No output schema documented. No error handling guidance. No composition patterns evident. Limited domain specificity for WHOIS response structure.

• Expand tool description to 100-150 characters. Include: what WHOIS information is returned (registrant, nameserver, dates), when an LLM should call this (domain ownership verification, registrant lookup), and key response fields (registrar, expiry_date, status).
• Add detailed description to 'domain' parameter: 'Domain name to look up (e.g., example.com). Accepts TLDs like .com, .org, .net. Automatically stripped of https://, http://, and www. prefixes. IDN/international domains supported. Required.'
• Document the output schema explicitly in the tool description or as a JSON example. Include fields returned (e.g., domain, registrar, creation_date, expiry_date, status, nameservers) and data types.
• Add error handling guidance: 'If domain is invalid or not found, the tool returns an error with the invalid domain name and valid format constraints. Verify domain syntax before retrying. Some TLDs may not support WHOIS lookups.'
• Specify domain validation rules: 'Validates domain with commons-validator (DomainValidator). Sanitizes input by removing protocols and www. prefix. Domains must be lowercase, non-empty, and valid per RFC 1035.'
• Consider adding retry guidance for transient failures: 'If WHOIS service is temporarily unavailable, retry after a short delay. Some registries rate-limit lookups, add backoff if receiving 429 errors.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry