If you are connecting Get on Board to your recruiting stack, the short answer is: use the API when a developer is building something programmatic — ATS sync, job publishing, webhooks, reporting pipelines. Use the MCP server when you want to work conversationally from an AI tool you already use — Claude, ChatGPT, Codex, or Cursor — to search Talent Database and read your open jobs in plain language, with no code involved. Many teams end up using both; they solve different problems and do not compete with each other.
The two integrations at a glance
| API | MCP server | |
|---|---|---|
| Built for | Developers writing code | Recruiters working inside an AI tool |
| Talks to | Your ATS, scripts, internal systems | Claude, ChatGPT, Codex, Cursor, and other MCP clients |
| Can write data | Yes: create, update, publish, and close jobs; move applications | No: read-only in the current version |
| Talent Database search | No | Yes, from a plain-text brief |
| Setup | Generate an API key in your company settings | Paste one URL and sign in with your Get on Board account |
| Access | Public endpoints open; private API needs a plan with API access | Recruiter team members with accepted company access |
When the API is the right choice
Choose the API when the goal is a system talking to a system, without a person in the loop:
- Keep jobs and applications in sync with an external ATS, or build a custom connection where no ready-made integration exists.
- Create, update, publish, unpublish, or close jobs from another tool.
- Receive webhooks when applications arrive, so your own systems react automatically.
- Feed dashboards, BI tools, or a custom career site with job and application data.
The API is a developer surface: it needs someone comfortable with endpoints and authentication. For everything it covers, start with What can I do with Get on Board’s API? and keep the technical API documentation as the reference for endpoints, payloads, and authentication.
When the MCP server is the right choice
Choose the MCP server when a recruiter wants to do the work by describing it, not by coding it. Once connected, the AI tool you already use can call five read-only tools with your own account and permissions: confirm your identity (whoami), search Talent Database from a natural-language brief (search_talent), read one candidate in depth (talent_profile), list your active hiring processes (list_jobs), and read a job’s full description and questionnaire (job_details).
That makes it the better fit for sourcing work like “read my open Backend Engineer job and shortlist 10 compatible candidates in Chile or Peru” — a conversation instead of an integration project.
Two boundaries to know before choosing it:
- It is read-only. An MCP client can search and read, but it cannot unlock candidates, invite them to a process, publish jobs, or change any data. Unlocking contact details stays in the Get on Board web app, where you spend credits with the usual confirmation flow. Read-only is also what makes the connection safe to hand to an agent: a misconfigured agent cannot spend your credits or contact anyone.
- It never returns contact data — no emails, phones, CV files, or social links. On Get on Board, professionals own their data, and the MCP server is built so that ownership survives the connection. What you get are search results, safe profile summaries, and links to open each profile in the web app.
The MCP server is available to recruiter team members with accepted access to a company; there is no professional-side access. For the full capability map, see What is the Get on Board MCP Server?
How setup differs
The API works with an API key: your company generates one in its API settings (private API access requires a plan that includes it), and a developer uses it in code. If you want to evaluate it first, see How can I test Get on Board’s API before purchasing a plan?
The MCP server needs no key and no code. You paste https://www.getonbrd.com/mcp into your client, sign in to Get on Board in the browser, pick the company to authorize, and approve. The connection expires after 2 hours, so re-authorizing during a long session is normal. Step-by-step guides:
Can I use both?
Yes, and it is a common pattern: the API keeps your ATS and internal systems in sync in the background, while recruiters use the MCP server for day-to-day sourcing conversations. They authenticate separately — an API key never works on the MCP server, and an MCP connection grants nothing to the API — so adopting one does not commit you to the other.