All 5 tools have explicit schemas with type definitions and descriptions. Naming follows verb_noun pattern (list_*, get_*). However, descriptions are minimal (10-40 chars), parameter descriptions lack actionable constraints, output schemas are undocumented, and critical security issue: _apiKey exposed as a tool parameter instead of server-side injection. No error handling guidance, no pagination metadata (total count, next_cursor), and no documentation of what fields are returned. Baseline: avg tool description should be 194 chars; these average ~25 chars.

• Move _apiKey to server-side environment variable injection. Remove it from tool parameters. Update callTool() to read process.env.GREENHOUSE_API_KEY or similar.
• Expand tool descriptions to 100-200 chars. Include WHEN to use (e.g., 'Call this to retrieve all active candidates for bulk operations'), WHAT it returns (e.g., 'Returns array of candidate objects with id, name, email, phone'), and any limits (e.g., 'Results capped at 500 per page').
• Document output schemas for each tool. Add a comment block or JSDoc showing the structure of returned objects, e.g., 'Returns: { candidates: [{ id: number, name: string, email: string, ... }], total_count: number }'.
• Add pagination metadata to list tool responses. Return total_count and next_cursor (or page info) so LLMs know when to fetch more results. Document in tool descriptions: 'Supports pagination via page and per_page parameters. Returns total_count for result planning.'
• Wrap API calls in try-catch with actionable error messages. E.g., 'Candidate not found (ID: 123). Verify the ID is correct or call greenhouse_list_candidates to find valid IDs.' Categorize errors as retryable (network timeout) vs. user-fixable (invalid ID) vs. fatal (auth failure).