Single tool 'find_doctor' has a clear action verb and reasonable description (127 chars), but critical gaps undermine quality. Input schema uses Zod with optional query parameter and description present, but lacks type constraints (enum, pattern, length limits). No output schema is documented, the response includes 'structuredContent' with doctors array and metadata, but LLMs cannot infer the structure of Doctor objects or pagination behavior. No error handling guidance (what if query matches no doctors? what if the service fails?). The tool is read-only and low-risk, but definition incompleteness prevents confident LLM usage.

• Document the output schema explicitly. Define the Doctor object structure: { name: string, specialty: string, rating: number, imageUrl: string, ... }. Include field types, required properties, and what each field represents.
• Add input constraints to the 'query' parameter. Specify: max length (e.g., 200 chars), allowed characters, and what happens if query is empty (returns all doctors vs. error). Replace examples with an enum or pattern if only certain specialties are valid.
• Add error handling guidance. Describe what the tool returns if no doctors match (empty array vs. error), and what the LLM should do next (e.g., 'If no match, try a broader query or ask the user for clarification').
• Implement pagination. Add optional 'limit' (default 20, max 100) and 'offset' parameters. Return 'total_count' and 'has_more' in the response so LLMs can fetch additional results if needed.
• Enhance the tool description with context. Add: 'Returns a list of qualified medical professionals matching the query. Each doctor includes name, specialty, rating, and contact info. Useful for helping users find specialists for their medical needs.'