15 tools with consistent naming (verb_noun pattern: get_*, search_*) and basic schemas. All tools are READ_ONLY, reducing risk. However, descriptions are minimal (10-30 chars), parameter descriptions lack detail, and output schemas are undocumented. No error handling guidance. Tool descriptions fail to explain WHEN to use each tool vs. similar ones (e.g., people_get vs people_search), and lack dependency hints. Parameters like 'fields' (array) and 'search' (object) lack type constraints and usage examples. No pagination guidance despite page/page_size params. Schemas present but sparse, missing min/max bounds, enum constraints, and output structure documentation.

• Expand tool descriptions to 50-200 characters. Example: 'Get all people in the database' → 'Retrieve all people in the Elvanto database. Use this for bulk exports or discovery. For finding specific people, use people_search() instead. Returns up to 25 records per page by default.'
• Add parameter descriptions with constraints. For 'fields' array: 'Comma-separated list of fields to return (e.g., first_name, last_name, email). Omit to return all available fields.' For 'search' object: 'Field-to-keyword map for filtering (e.g., {"first_name": "John", "email": "[email protected]"}). All fields are AND-combined.'
• Document output schemas in tool descriptions. Example: 'Returns {"people": [{"id": "...", "first_name": "..."}], "total": 1234, "page": 1, "page_size": 25}' or link to API docs.
• Add error handling guidance to descriptions. Example: 'If the search returns no results, try broadening the search terms or use people_get_all() to browse all records. If you receive a 401 error, the API key may be invalid.'
• Specify pagination bounds in descriptions: 'page_size defaults to 25, max 1000. page starts at 1. If results exceed 100,000 characters, they are truncated with a notice.'