Skip to content
Call wiki

What can Ashby's official MCP server do, and when do you need the REST API?

Last updated 2026-08-25 · Confidence: documented — Ashby’s knowledge base, product update, and API reference (OpenAPI schema included); that a credited submission shows up as the user’s own in Ashby’s UI is inferred.

Ashby’s MCP server reads most of the pipeline but writes only notes, stage changes, candidates, and “consider for job”. Submitting feedback — including in a specific user’s name, tied to an interview event — is an API call (applicationFeedback.submit), so a work-test scoring flow needs an API key or a custom MCP wrapping it.

The MCP server: per-user OAuth, four write actions

Section titled “The MCP server: per-user OAuth, four write actions”

An org admin turns it on under Admin → Organization Setup → Opt In Features; each user then connects via OAuth and “the MCP server authenticates each user individually” — it returns only what that user can already see in Ashby, per the beta docs. No shared service account, no separate permission model.

Reads cover candidates, applications, jobs, openings, interviews, offers, pipeline status, pending tasks, and the user’s own submitted feedback. The write list is short:

  • create candidates
  • add notes to a profile
  • change application stage
  • consider a candidate for a job

Tool inputs and outputs “may change without notice”, so list the tools from a connected client before designing around them. Like the Asana connector, it installs as a custom connector at https://mcp.ashbyhq.com/mcp/v1.

The API: admin-created keys with per-module read/write

Section titled “The API: admin-created keys with per-module read/write”

Keys are created at Admin → Integrations → API Keys (Covey setup guide) and only an Ashby Admin can manage their permissions. The authentication reference grants read or write per module — Jobs, Candidates, Interviews, Hiring Process, Offers, and so on — with separate opt-ins for confidential jobs, private fields, and “Allow acting on behalf of a user”. There is no admin-only endpoint tier; the key’s module grants decide.

Endpoints the MCP lacks, all under candidatesWrite: applicationFeedback.submit, assessment.addCompletedToCandidate (a scored result on a candidate or application), candidate.addTag, candidate.uploadFile, and interviewSchedule.create.

Feedback in a user’s name, tied to an interview

Section titled “Feedback in a user’s name, tied to an interview”

applicationFeedback.submit takes applicationId, formDefinitionId, fieldSubmissions (score fields are { score: 1–4, comments }), an optional interviewEventId, and userId — “the id of the user the feedback will be credited to. If omitted, the feedback will be credited to the API key user.” The X-On-Behalf-Of header attributes any request to a user for “creating notes or submitting feedback”. applicationFeedback.list returns both submittedByUser and creditedToUser (inferred that the credited user sees it as their own scorecard — submit one test feedback and check the interviewer’s view).

Sources

Section titled “Sources”