Ashby MCP Server: Setup, Tools, and the Webhook Gap
Yes — Ashby has an official MCP server, and it’s from Ashby itself, not a community project. It’s a hosted remote server at https://mcp.ashbyhq.com/mcp/v1, it authenticates each user individually over OAuth, and it’s in open beta on every Ashby plan, with analytics-only organizations excluded. Connected, it lets an AI read your candidates, applications, jobs, interviews, offers, notes, and feedback — and write back: create a candidate, add a note, move an application to the next stage, consider someone for an open role.
The part worth understanding before you wire it up is what “MCP server” actually buys you. It’s a doorway into Ashby that an AI can walk through when you open a chat and ask it to. Nothing watches your pipeline. No application landing, no stage change, no unsubmitted scorecard starts anything. Below: what the server exposes, how to connect it, the API and webhook layer underneath, and what to use when you want Ashby work that runs without a recruiter babysitting a chat window.
Ashby is one of many — the complete list of MCP servers covers every app that ships one, grouped by category.
What the Ashby MCP server exposes
Model Context Protocol is the open standard that lets an AI client talk to an outside app through a shared interface. Ashby announced MCP support in May 2026 as part of Ashby One, then took the server to open beta for all customers at the end of June.
It’s client agnostic — Claude, ChatGPT, Cursor, or anything else that speaks MCP. And critically for a recruiting tool, it inherits your permissions: you connect through OAuth as yourself, so the AI can only see and touch what your own Ashby login already can. A coordinator’s connection doesn’t suddenly expose compensation data a coordinator can’t see.
On the read side it searches and retrieves across candidates, applications, jobs, job postings, interviews, offers, notes, feedback, emails, referrals, and hiring teams. In practice that means questions like:
- “Which candidates have been sitting in onsite for the Staff Engineer req for more than ten days?”
- “Summarize the interview feedback on this finalist and show me where the panel disagreed.”
- “List every offer extended this quarter and its current status.”
On the write side it’s deliberately narrower — a handful of actions rather than full control of your ATS: create a candidate, add a note to an application, move an application between interview stages, and consider a candidate for an open job.
Worth knowing about the ceiling: requests are capped at 120 per minute per auth token, with a parallel budget of 120 tool units per minute where most tool calls cost one unit and filtered searches cost two. Fine for a recruiter asking questions. Not a bulk-processing pipe.
How to connect Ashby to Claude or ChatGPT
The directory listings have landed, so this no longer requires developer mode or hand-pasting a URL:
- In Claude — open Customize > Connectors, search for Ashby, and select it.
- In ChatGPT — open Settings > Apps, search for Ashby, and select it.
- Complete the OAuth login and approval prompt. You’re authorizing under your own Ashby account and its existing permissions.
- Confirm the tools appear, then ask it to look up a single candidate before you trust it with anything that writes.
Any other MCP-compatible client can point at https://mcp.ashbyhq.com/mcp/v1 directly. Ashby documents the current setup and tool list in its MCP server docs. If you’re setting this up on the ChatGPT side specifically, connecting MCP servers to ChatGPT covers the client-side mechanics, and we have longer walkthroughs for Ashby with Claude and Ashby with ChatGPT.
The API and webhooks underneath
The MCP server is a wrapper over Ashby’s developer API, and it’s worth knowing that layer exists — because it’s where the capability MCP lacks actually lives.
Getting an API key takes an admin. Go to Admin > Integrations > API Keys and hit + New. If you don’t see the option, you’re not an admin and you’ll need one to do it. Keys authenticate with HTTP Basic auth (the key as username, blank password). It isn’t plan-gated the way MCP’s analytics-only exclusion is, but it is scoped: new keys start with zero permissions, and you check read and/or write per module. Call an endpoint the key wasn’t granted and you get a 403. There are two extra flags worth deciding deliberately — whether the key can reach confidential jobs and projects, and whether it can read non-offer private fields. Grant only what a given workflow needs.
Webhooks are the important half, because this is the thing MCP structurally does not have. Ashby fires real events at a URL you own, configured under Admin > Integrations > Webhooks. The ones that matter to a recruiting team:
applicationSubmit— a candidate applies, or is manually added (it does not fire for bulk imports or integration syncs)candidateStageChange— someone moves through your interview plancandidateHire— closed wonapplicationUpdate— including applications transferred to another jobinterviewScheduleCreateandinterviewScheduleUpdate— scheduling and reschedulesinterviewPlanTransition— movement between plan phasesofferCreateandofferUpdate— offer out, offer changedjobPostingPublish,jobPostingUnpublish,jobPostingUpdate,jobUpdate— req-level changes
Set a secret token when you create one and Ashby cryptographically signs every request with an Ashby-Signature header — do this, it’s the difference between a real integration and an open endpoint. One operational gotcha: if your endpoint returns a failure, Ashby disables that webhook until someone manually re-enables it. Silent pipeline automations die this way.
One honest gap: there’s no webhook for a submitted interview scorecard. Feedback is readable through the applicationFeedback.list endpoint, so “who still owes feedback” is a question you answer by checking on a schedule, not something that fires the moment it happens — or fails to.
Where the Ashby MCP server stops
None of this is a knock on the protocol. It’s just the shape of it:
There is no such thing as an MCP trigger. The protocol's own working group states plainly that clients find out about server-side changes by polling for them, and a real event mechanism remains unshipped.
For a recruiting team that limitation is unusually expensive, because the moments that cost you candidates are all events:
- A strong candidate goes cold. Five days in “Recruiter Screen” with no activity is how good people end up at another company. The MCP server will tell you — accurately — the moment you think to ask. That’s the problem.
- An interview needs scheduling.
candidateStageChangefires the instant they advance. MCP can’t hear it, so the coordinator hears it when they next check. - A scorecard hasn’t been submitted. The panel finished Tuesday. Nobody notices until the debrief on Friday, and now the decision slips a week.
The other two limits: it’s one app at a time (Ashby knows Ashby — getting a candidate into Slack, your calendar, and a comp sheet means wiring and authorizing a separate server for each), and you own the scopes — read/write access to candidate records is real blast radius in a system holding compensation and confidential reqs.
So the Ashby MCP server is a genuinely good way to interrogate your pipeline and make one-off edits. It is not a way to make Ashby run.
Making an Ashby event start real work
That gap — reacting to something the moment it happens, across every app the candidate touches — is where Carly fits. Carly connects to Ashby natively, so there’s no MCP server to host and no API key to mint, plus ~260 other apps and anything with a public API through your own key, which you paste into Carly at carlyassistant.com/integrations.
Both ChatGPT and Claude will now do work on a schedule, unattended. Neither reacts to events. A task that runs hourly still finds out an hour late, and one that runs each morning finds out tomorrow — the trigger is the clock, never the thing you actually care about.
That’s the whole difference. Carly’s workflows are triggered and scheduled, so they fire on the Ashby events above rather than waiting to be asked:
- When an application is submitted for a priority req → summarize the resume against the scorecard criteria, post it to the hiring channel in Slack, and flag anything that looks like a referral.
- When a candidate moves to onsite → pull the panel’s availability, draft the scheduling email, and open the interview slot before the coordinator has read the notification.
- When a candidate sits in one stage past your SLA → nudge the owning recruiter with the specific candidates and how long each has been stuck.
- Every morning → check which interviews happened yesterday and whose scorecard is still outstanding, then message those interviewers directly.
The moving, matching, and routing between apps — the Zapier-style backbone — is free and unlimited. The AI steps, the summarizing and drafting and deciding, start at $35/month. You describe the outcome in plain language and Carly wires up the Ashby connection and everything downstream.
FAQ
Does Ashby have an official MCP server?
Yes. Ashby builds and maintains its own MCP server at https://mcp.ashbyhq.com/mcp/v1. It’s in open beta on all Ashby plans except analytics-only organizations, it authenticates each user individually over OAuth, and it works with any MCP-compatible client including Claude, ChatGPT, and Cursor. You don’t need a third-party or community server.
Is the Ashby MCP server read-only? No, but the write access is narrow. It reads broadly across candidates, applications, jobs, interviews, offers, notes, and feedback, and it can write in a few specific ways: creating a candidate, adding a note, moving an application between interview stages, and considering a candidate for an open job.
Can the Ashby MCP server notify me when a candidate applies?
No. MCP has no triggers and no scheduler — nothing runs unless you open a chat and ask. Ashby does fire an applicationSubmit webhook, but consuming it requires something that listens for events, which an MCP connection is not. That’s what a workflow tool like Carly handles.
Do I need an Ashby API key to use the MCP server? No. The MCP server uses OAuth, so you authorize as yourself with no key to generate. API keys are a separate path under Admin > Integrations > API Keys, they require admin access, and they start with no permissions until you grant read or write per module.
Ready to automate your busywork?
Carly schedules, researches, and briefs you—so you can focus on what matters.
See what people say
"Before Carly, I relied on a Calendly link, but the whole process felt impersonal and not very professional. Carly changed that by handling all the back-and-forth, so I'm no longer stuck in endless email threads trying to line up schedules.
Now Carly reaches out to candidates, shares my real-time availability, lets them pick a slot, then sends a Zoom link and drops it straight into my calendar. She sends reminders to both of us before each call, which has significantly reduced no-shows and last-minute confusion.
On top of scheduling, Carly acts like a full executive assistant, sending me my schedule the night before so I can prepare for each call. It reminds me of the old x.ai assistant, but Carly is noticeably smarter, faster, and better suited to my healthcare recruitment business."
