Four tools with clear verb-noun naming (get_proxy, list_proxies, proxy_status, check_proxy) and complete input schemas. All parameters have type and description. Tool descriptions are present (avg 95 chars) but lack actionable context for LLM selection, they state WHAT but not WHEN or WHY. No output schemas documented; responses are free-text JSON requiring LLM parsing. Error handling returns plain error strings without recovery guidance. Missing parameter constraints (e.g., IP format validation, port ranges). No mention of idempotency guarantees or retry safety despite idempotentHint annotations.

• Document output schemas for all tools. Define the structure of JSON responses (e.g., get_proxy returns {ip, http_port, socks_port, username, password, protocol}). Include field types and descriptions.
• Expand tool descriptions to 150 - 250 chars. Add WHEN to use each tool and how it differs from similar tools. Example: 'Get a single proxy IP with credentials in URL or JSON format. Use this to configure a client. Call list_proxies first if you need all assigned IPs.'
• Wrap error responses in structured objects with error_code, message, and recovery_hint. Example: {error_code: 'NO_PROXIES_ASSIGNED', message: 'No proxy IPs assigned to this service', recovery_hint: 'Contact support to add IPs to your plan'}.
• Add format validation to the 'ip' parameter in check_proxy. Describe expected format: 'IPv4 address (e.g., 192.0.2.1). If empty, checks the first assigned proxy.'
• Document idempotency guarantees explicitly in tool descriptions. State whether repeated calls with the same input are safe to retry without side effects.