All 5 tools have explicit schemas with type definitions and descriptions. Naming follows verb_noun convention (list_*, get_*). However, descriptions are minimal (34-76 chars, below the 50-200 char baseline for LLM optimization), parameter descriptions lack actionable constraints (no enums, ranges, or format guidance), and output schemas are completely undocumented. The _apiKey parameter is exposed as a tool input rather than injected server-side, violating secret-injection pattern. No error handling guidance, no pagination details, and no indication of what fields are returned.

• Move _apiKey to server-side environment variable injection. Remove it from tool parameters. Use process.env.ASHBY_API_KEY or a config object passed at initialization.
• Document output schemas for each tool. Example for ashby_list_candidates: 'Returns {results: [{id, name, email, ...}], nextCursor?: string, total?: number}'. Include all fields the LLM needs to chain calls.
• Expand descriptions to 80-150 chars. Example: 'List all candidates in Ashby. Use this to discover candidates before calling ashby_get_candidate for details. Supports pagination via cursor. Returns up to 50 per page.'
• Convert 'status' parameter in ashby_list_jobs to an enum: {type: 'string', enum: ['open', 'closed', 'draft', 'archived'], description: 'Job status filter...'}. Repeat for any other constrained parameters.
• Add error handling with recovery hints. Wrap ashbyPost() errors: if 401, suggest 'Invalid API key. Verify ASHBY_API_KEY is set correctly.'; if 404, suggest 'Candidate not found. Try ashby_list_candidates() to find valid IDs.'