Ashby MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ASHBY_API_KEY | Yes | Your Ashby API key. Generate one at https://app.ashbyhq.com/admin/api/keys with candidatesRead, jobsRead, and candidatesWrite permissions. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| job_listA | List all jobs (open, closed, archived). Supports cursor pagination and status filtering. |
| job_infoB | Get details of a single job by its ID. |
| job_searchB | Search for jobs by title. Not paginated; returns all matches. |
| candidate_listC | List all candidates with cursor pagination. |
| candidate_searchA | Search candidates by email and/or name. Not paginated. |
| candidate_infoC | Get full details of a single candidate by ID. |
| candidate_createC | Create a new candidate in Ashby. |
| candidate_create_noteC | Add a note to a candidate. Supports HTML formatting. |
| candidate_list_notesC | List all notes for a candidate. |
| candidate_add_tagB | Add a tag to a candidate. Use candidate_tag_list to find tag IDs. |
| candidate_tag_listB | List all available candidate tags. |
| application_listA | List applications. Can filter by jobId and/or status. Uses cursor pagination. |
| application_infoB | Get full details for a single application by ID. |
| application_createC | Create an application linking a candidate to a job. |
| application_change_stageC | Move an application to a different interview stage. |
| interview_stage_listC | List all interview stages for a given interview plan. |
| interview_plan_listC | List all interview plans. |
| interview_listB | List all interviews with cursor pagination. |
| interview_infoB | Get details of a single interview by ID. |
| department_listC | List all departments. |
| user_listB | List all users (team members) in the organization. |
| source_listC | List all candidate sources. |
| archive_reason_listA | List all archive reasons (needed for application_change_stage to Archived). |
| location_listB | List all locations. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Every tool has a clearly distinct purpose with no ambiguity. For example, application_list and application_info are clearly separate from candidate_list and candidate_info, and specialized tools like archive_reason_list or candidate_tag_list serve unique functions. The descriptions reinforce distinct boundaries between tools.
All tools follow a consistent verb_noun pattern with underscores, such as application_change_stage, candidate_create, and job_list. There are no deviations in naming conventions, making the set predictable and easy to parse for an agent.
With 24 tools, the count is slightly high but reasonable for an ATS domain covering applications, candidates, jobs, interviews, and metadata. Each tool appears to earn its place by addressing specific aspects of the hiring workflow, though it borders on being heavy.
The tool surface provides comprehensive CRUD and lifecycle coverage for the Ashby ATS domain. It includes creation (e.g., candidate_create, application_create), retrieval (e.g., info and list tools), updates (e.g., application_change_stage, candidate_add_tag), and supporting metadata (e.g., department_list, source_list), with no obvious gaps that would cause agent failures.