ProxyDoctor exposes 5 tools with basic HTTP endpoints. Tool names follow verb_noun convention (get_*, start_*, stop_*), which is good. However, parameter descriptions are minimal or absent. The diagnose tool has reasonable parameter documentation (url, proxy, proxy_type with enum), but get_checks, get_local_proxy_status, start_local_proxy, and stop_local_proxy lack parameter descriptions entirely. Output schemas are not documented in the source, responses are inferred from JSON encoding but not formally specified. Error handling is present (writeJSONError) but generic ('diagnosis failed: ...'). No tool annotations (readOnlyHint, destructiveHint) are visible. The server is functional but falls short of production-grade tool definition quality.

• Document output schemas for all tools. Specify the structure of checkInfo, diagnosis report, proxy status, and start/stop responses. Include field types and descriptions.
• Add parameter descriptions to get_checks, get_local_proxy_status, start_local_proxy, and stop_local_proxy. Even empty input schemas need a description explaining what the tool returns.
• Add tool annotations: mark get_checks, diagnose, get_local_proxy_status as readOnlyHint=true; mark start_local_proxy and stop_local_proxy as destructiveHint=true.
• Enhance error messages with recovery guidance. E.g., 'Invalid proxy URL: expected format http://host:port or socks5://host:port. Check proxy parameter.' instead of generic 'invalid JSON body'.
• Add limit and offset parameters to get_checks to support pagination and prevent context window exhaustion on large check registries.