RecruitingConnector
Greenhouse
Read Greenhouse candidates, jobs and applications, create a candidate and add notes, from Claude or ChatGPT through Tulina's MCP server and a Harvest API key.
Official site: www.greenhouse.io
What it can do
2 read/2 write
- 01Read
List and read candidates, with their applications
- 02Read
List and read jobs and applications, filtered by status
- 03Write
Create a candidate
- 04Write
Add a note to a candidate, with its visibility
The connector uses Greenhouse's Harvest API. Candidates, jobs and applications can be read, and two things can be written: a new candidate and a note on a candidate's activity feed. Every write is made on behalf of a named Greenhouse user, which the agent looks up first, so a write is attributed to a person.
Does Greenhouse have an MCP?
Yes. Greenhouse runs its own, described in its help centre as a governed way to connect approved AI tools to your hiring data. A Site Admin starts the connection in a supported client, such as Claude or ChatGPT, and users sign in with OAuth 2.0 using the email tied to their Greenhouse Recruiting account. Admins set the scopes in Dev Center, MCP Access, and those scopes are a ceiling for every user. Greenhouse's article says it supports both read and write actions, is available on its Core, Plus and Pro tiers and not on legacy ones, and, as of October 2026, is in open beta.
How do you connect Greenhouse to Claude and ChatGPT?
Through Tulina's MCP server, in three steps:
- In Greenhouse, open Configure, Dev Center, API Credentials and create a key of type Harvest. Give it the candidates, jobs, applications and users permissions.
- Paste the key into Tulina's Greenhouse connector, for yourself or for the organisation. It is stored in the vault and never shown to the model. The connector is outside the base set and is activated per organisation.
- Add
https://mcp.tulina.ai/mcpto Claude or ChatGPT and sign in with your Tulina account. The MCP page has the same link.
Tulina vs Greenhouse's official MCP server
Both reach your hiring data. The difference is who signs in and who sets the ceiling.
| Greenhouse's MCP server | Tulina | |
|---|---|---|
| Sign-in | OAuth 2.0 with PKCE, per user | A Harvest API key, held in Tulina's vault |
| Who enables it | A Site Admin, with scopes set in Dev Center | Whoever can create a Harvest key |
| Ceiling | The scopes the admin approved, and each user's own Greenhouse permissions | The permissions given to the key |
| Availability | Core, Plus and Pro tiers | Tulina's connector, activated per organisation |
| Reads | Live hiring data; the article does not list the tools | Candidates, jobs, applications and users |
| Writes | Read and write, scope dependent | Create a candidate, add a note |
| In the same conversation | Greenhouse | Greenhouse plus Slack, your inbox, your calendar and the other connected tools |
If your team already runs Greenhouse's governed access and wants each recruiter's own permissions applied, Greenhouse's server is the better choice. Tulina suits a shared, key-based setup, or a workflow where the funnel is one input among several.
What you can ask it
"Which candidates applied to job 123 this month?" The agent lists candidates with the job filter and a created-after date, then reads each candidate it needs to show their applications.
"Show me every active application on the open Staff Engineer job." The agent lists open jobs, picks the one you named, then lists its applications with the active status. Rejected and hired applications are separate filters.
"Add a private note on candidate 456: reference call done, positive." The agent first lists Greenhouse users to find your user id, then adds the note with that id as author and the visibility you chose, which is admin only, private or public. Public is the default, so ask for private when you mean it.
For teams that compare trackers, Ashby and Lever sit in the same Recruiting category, and Slack carries the digest.
What the Greenhouse connector can't do
- Jobs and applications are read-only. It does not create a job, advance an application or reject one.
- It does not edit or delete a note, or a candidate.
- Every write needs a Greenhouse user id to act as. Without one the write is refused.
- A note defaults to public visibility, which the hiring team can read. Say private or admin only when that is what you want.
- Candidate search filters on job, exact email and created or updated dates. There is no free-text name search.
- Lists are paged, 50 per page by default and 500 at most.
- It has no dedicated tool for scorecards, interview schedules or offers.
- Access is the key's. Everyone using the connector acts within the permissions it was created with.
Why through Tulina
The connection was never the hard part.
Most systems now publish their own way for a model to reach them, and that is good: it is what Tulina connects to. The hard part is deciding who may use it, what it is allowed to return, and what the model knows before it asks.
The keys stay in one place
YouTeamOrganisation
Connect Greenhouse once. The credential is encrypted in a vault, never held in clear, and never pasted into a chat or a workflow file. A person uses their own key where they have one, their team's where they do not, the organisation's after that, so nobody is blocked and nobody holds more access than they need. Revoke it once and everything running on it stops.
What leaves is filtered before it leaves
fields droppedmasked or hashedpseudonymised
Roles decide who can reach Greenhouse at all. Beyond that, a policy on the connector itself decides what comes back. The data is minimised at the source rather than after it has already reached a model.
Every call is on the record
whatwhowhen
Runs are logged for the organisation. That is what makes an automated action reviewable after the fact, and it is what a security review asks for first.
The run starts knowing your company
namingkey accountsdecisions
A direct connection gives a model access. It does not tell it how your company names things, which accounts matter, or what was decided last quarter. Tulina carries that across every tool, so the same request against Greenhouse returns something usable instead of something generic.
Processes that run on Greenhouse
None published yet.