Single tool 'sms_validate_number' has a well-structured schema with proper types and descriptions for both parameters. The tool description is comprehensive (280+ chars) and includes use cases, expected output format, and explicit guidance on when NOT to use it (pattern:tool-description). However, the description embeds example output JSON and example use cases that could be misinterpreted by LLMs as literal values. The schema is complete with required fields and type definitions, meeting baseline standards. No error handling guidance is documented, the tool does not explain what happens on invalid input, network failure, or unsupported country codes. Output schema is described in prose but not formally documented as a JSON schema structure.

• Add formal JSON schema for the response object: {type: 'object', properties: {phone: {type: 'string'}, canReceiveSMS: {type: 'boolean'}, ...}, required: [...]}, so LLMs can reliably parse output.
• Replace example output JSON in description with constraint documentation: 'Returns a JSON object with fields: phone (E.164 format), canReceiveSMS (boolean), carrierType (enum: mobile|landline|voip), ...'
• Document error cases explicitly: 'Returns error if phone number is malformed, country code is unsupported, or API is unreachable. Retry with exponential backoff on network errors.'
• Clarify countryCode parameter: 'Optional ISO 3166-1 alpha-2 code (e.g. US, FR). If omitted, inferred from phone number prefix. Provide if phone number lacks country code prefix.'
• Add rate limit guidance: 'This tool is rate-limited to 100 calls/minute per API key. Batch validation requests where possible; implement exponential backoff on 429 responses.'

Inferred effective spec: 2025-06-18+.

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