Connect Greenhouse to Claude, ChatGPT and Cursor with governed access

Monday, 08:40. A Head of Talent has a pipeline review at ten and four questions she cannot answer from memory: which requisitions slipped a stage last week, which candidates are sitting in a loop with no scorecard filed, how many offers are outstanding against approved headcount, and whether campus hiring produced anything at all. Every answer is in Greenhouse. Getting them by ten means opening several reports, exporting two of them, and reconciling the totals by hand into a spreadsheet that will be wrong again by Wednesday.

She would rather ask Claude. The model was never the obstacle. The obstacle is that giving an assistant a Greenhouse credential has historically meant giving it the whole of Greenhouse: EEOC responses, offer compensation, and the scorecards interviewers wrote on the understanding that only the panel would read them. Recruiting, hiring managers, people ops and finance all work in the same system and all need different parts of it. One shared credential erases those differences on contact.

Elaichi separates the credential from the permission to use it. Greenhouse is connected once, by someone who should hold that key. Each team gets a toolbox scoped to the records it actually works with. Every call resolves against the person who made it, and every call is written to an append-only log.

Six teams, one applicant tracking system

Greenhouse looks like a recruiting tool from outside. Inside a company of any size it is shared infrastructure, and the list of people with a legitimate reason to query it runs well past the recruiting org.

Recruiting lives in candidates and applications. A coordinator's day is moving people between stages, chasing feedback, and knowing which applications arrived overnight. That work needs depth: individual records, not aggregates.

Hiring managers care about jobs and the interview stages beneath them. A manager wants their own requisitions, the loop for each, and who is scheduled this week. They have no business reading candidates attached to another team's jobs, and most would rather not.

Talent sourcing works in sources and tags. The question is which channels produce people who convert, which is a wide read across many candidates and almost never a deep read into one person's file.

People operations owns departments and users. This is the team that knows who has left, which requisition belongs to which org unit, and which accounts should no longer exist. It is also the only team with a real reason to change structural records rather than read them.

Finance tracks offers and headcount. Offers carry compensation, which is a narrower audience than the recruiting team itself.

Exec wants pipeline reporting: movement, conversion, time in stage, and almost never a named individual.

Same system, six defensible and different answers to the question of what should be reachable.

Connecting Greenhouse, and why no consent screen appears

Greenhouse authenticates with an API key, and that single fact shapes everything downstream, so it is worth being blunt about what does not happen. No vendor window opens. Nobody approves anything. There is no per-person grant, and no moment at which an individual employee's own Greenhouse permissions are consulted by Greenhouse. Someone with administrative rights there generates a key, decides at that moment what the key may reach, and pastes it in once.

The consequence is that the credential's reach is fixed before Elaichi ever sees it, by whoever created it. Scoped narrowly, no later configuration can widen it. Scoped to everything, every control from that point on is Elaichi's to enforce. Either way a human made the call, not a protocol, so the person who creates the key should be the person accountable for the data behind it. Usually that is the Head of Talent or a people ops lead, not whoever happened to be setting up tooling that afternoon.

The mechanics are short. Open Connections, choose Add connection, pick Greenhouse, paste the key, optionally set Share with, then Connect. You land on Connection added.

Share with earns its keep here precisely because there is no per-person grant. Sharing is how people use that key without ever holding it. Give a team Use and its members can run tools against the connection while being unable to open it, edit it, transfer it, or even see it listed. Give View to a reviewer who needs to know the connection exists without firing anything through it. Reserve Edit for the few who should be able to change its settings and its sharing. Delegated use is re-checked against the owner every time it resolves, so it dies when the owner's access does. No orphaned key, nothing living on in a departed employee's name.

Which Greenhouse tools each department should see

The connector exposes 52 tools. Nothing in that catalogue deletes a record and very little writes, so the risk here is not blast radius. It is read scope. A coordinator reading EEOC responses is a real incident even though nothing changed.

The useful sorting question is not read versus write. It is which department has a standing reason to hold this record, and whether the tool returns one person or a shape. Start there, and most of the catalogue sorts itself.

Recruiting gets list_all_greenhouse_candidates, get_single_greenhouse_candidate_by_id, list_all_greenhouse_applications and get_single_greenhouse_application_by_id. That is the deepest read in the system and it belongs to the team whose job is the individual.

Hiring managers get list_all_greenhouse_jobs, get_single_greenhouse_job_by_id, list_all_greenhouse_job_stages and list_all_greenhouse_scheduled_interviews. Add list_all_greenhouse_application_scorecards only if your culture is that managers read the panel's written feedback. Many companies keep that to the panel, and list_all_greenhouse_scorecards is the tool to leave out of any toolbox you are not certain about.

Talent sourcing gets list_all_greenhouse_sources, list_all_greenhouse_tags and list_all_greenhouse_prospect_pools, plus list_all_greenhouse_job_posts and get_single_greenhouse_job_post_by_id for what the market actually sees.

People operations gets list_all_greenhouse_departments, list_all_greenhouse_users, list_all_greenhouse_user_roles and list_all_greenhouse_offices. They also get the tools that change things, create_a_greenhouse_office and update_a_greenhouse_office_by_id. Office records are structural rather than candidate data, and one team should own them.

Finance gets list_all_greenhouse_offers, list_all_greenhouse_application_offers, list_all_greenhouse_job_openings and list_all_greenhouse_pending_approvals. Offers are the compensation surface. Keep the list exactly this short.

Exec gets list_all_greenhouse_jobs, list_all_greenhouse_job_stages and list_all_greenhouse_activity_feeds. That is enough to describe movement through the funnel without ever opening a named person's file, and it is the toolbox most likely to be asked for in a hurry before a board meeting.

Everything remaining is enabled deliberately or not at all. list_all_greenhouse_eeoc and get_single_greenhouse_eeoc_by_id should be the hardest tools in the organisation to reach.

One template, one toolbox per hiring scope

Write the definition once. A template is tool entries and their overrides with no connection attached, which makes it the right place to record a decision rather than a deployment.

Build a recruiting pipeline template holding list_all_greenhouse_candidates, get_single_greenhouse_candidate_by_id, list_all_greenhouse_applications, get_single_greenhouse_application_by_id, list_all_greenhouse_jobs and list_all_greenhouse_job_stages. Rewrite each description in the language your recruiters use, so an agent choosing between them chooses correctly. Switch the enabled toggle off on anything you want defined but dormant. If a tool exposes a filter for office or department, freeze it: a frozen parameter is stripped from the schema the model sees and merged over whatever the caller sent, so it is neither visible nor arguable. Precedence runs defaults, then caller arguments, then frozen values, and the frozen value wins.

Share the template with the people who run hiring, then stamp it once per scope: Recruiting EMEA, Recruiting Americas, Engineering hiring, Sales hiring, Campus hiring, People ops. Stamping binds connections to the entries and produces the object MCP clients actually connect to. Any entry left unbound shows as needs connection rather than failing quietly at call time.

Two properties to plan around. Stamping copies at creation, so editing the template next month leaves today's toolboxes untouched; a policy change means restamping or editing them directly. And entry lists cap at 200, which no per-department toolbox here will approach, and which is worth remembering the next time someone proposes a single toolbox containing the entire catalogue.

Governing it, starting from the log

Design backwards from the record you will one day have to produce.

The audit log is append-only by construction. No path in the product edits or deletes an entry, which is what makes it worth building policy around. It covers tool calls, memberships, roles, teams, connections and transfers, toolboxes, shares, restrictions, SSO and SCIM changes, and sign-ins. When a call creates or changes a record in Greenhouse, the id of that record is recorded.

Now the limitation that should drive your configuration. Arguments and results are not logged, deliberately, because a call's payload is candidate data. For a read-heavy connector like this one the log will tell you that a named person ran list_all_greenhouse_candidates at a given time through a given toolbox. It will not tell you which candidates came back. That has to be constrained in advance, through which tools sit in the toolbox and which parameters are frozen, because it cannot be reconstructed later.

Restrictions do the enforcing: allow-lists or block-lists over connectors and individual tools, aimed at a role or at one named member. There is no organisation-wide restriction, so a blanket rule is written per role. A member-level rule replaces that member's role rule instead of adding to it, which is why writing one is its own permission. Rules are checked at four points: connect time, when tools are listed, when one is called, and on the outbound request. They match the original catalogue tool name, so a friendlier renamed entry does not slip past. An allow rule naming nothing denies everything, which is the right starting position for EEOC and scorecard tools.

Give your compliance reviewer the Auditor role, one of the three that consume no billable seat. Keep connector:create rare; it is the only permission flagged high-trust, because a custom connector can be aimed anywhere and no restriction binds it afterwards.

On freshness, be exact with stakeholders. Every call is re-checked, but role and restriction changes read a snapshot up to about a minute old, two at worst. Revoking a share, disconnecting the connection, or removing a member takes effect on the very next request.

One endpoint, and what each person's client sees

Everyone points their AI client at the same organisation-wide address, copied from the Connect your AI client dialog. There is no per-user endpoint to distribute and no per-user credential to rotate. Setup in each client is manual, which at rollout is a feature: somebody adds it on purpose.

What differs is what comes back. Tools resolve against the signed-in person, so a coordinator and a finance analyst pointing the same client at the same address see different catalogues.

On first connection the client asks for consent by category: Read, Create and change, Delete, and Run tools. Only Read is on by default, and for most Greenhouse rollouts that is all you want, since the two writing tools here are structural and belong to people ops.

One number to plan for. Past 30 advertised tools, counting the platform's own operations together with your connected ones, names are replaced by two generic entries, search_tools and execute_tool. At 52 tools a full Greenhouse toolbox crosses that line by itself. The search behind it ranks lexically rather than semantically, so asking about interview feedback will not surface list_all_greenhouse_scorecards. That is a further argument for narrow per-team toolboxes: under the threshold, the model sees real names.

Connect Greenhouse to Claude

Copy the endpoint from the Connect your AI client dialog. In Claude, open Settings, then Connectors, then Add custom connector, and paste it. Claude prompts for sign-in, and what appears afterwards is whatever that person's toolboxes allow. On Claude Team and Enterprise only an Owner can add a custom connector, so book a short window with whoever holds that role rather than sending instructions to the whole recruiting team. Approve Read at consent time. Add Create and change only for the people ops members who need create_a_greenhouse_office and update_a_greenhouse_office_by_id.

Connect Greenhouse to ChatGPT

In ChatGPT, open Settings, then Apps, turn developer mode on, choose Create, paste the endpoint and run Scan tools. The scan is what pulls your catalogue in, so when a recruiter sees fewer tools than expected, the toolbox they are in is the place to look rather than the client. This path is available on Business, Enterprise and Edu plans, and it is web-only, which matters if your hiring managers work mostly from a phone. Consent defaults to Read, which suits a pipeline-reporting toolbox built entirely from list tools.

Connect Greenhouse to Cursor

Cursor reads MCP servers from a JSON file, so this one is set up per machine rather than per account. Add an entry under mcpServers in ~/.cursor/mcp.json on the person's own machine, or in a repository's .cursor/mcp.json if a shared repo is where your team keeps configuration. Per machine means a laptop swap requires doing it again, while access still resolves against the person once they sign in. Useful for the analyst who builds pipeline reporting next to the code that renders it.

Day two

Keys expire, get rotated, or get revoked by someone tidying up in Greenhouse. The connection breaks and the fix is Reconnect, which repairs it in place and leaves the toolboxes stamped against it alone. Nobody restamps anything.

Offboarding is the case worth rehearsing. Remove a leaver from the organisation and their access is gone on the next request, with no snapshot delay. If that person owned the Greenhouse connection, everyone using it by delegation was riding on their access, so transfer ownership before the removal rather than after. The transfer itself lands in the audit log.

Expect requests. In the first month after a rollout somebody will want a tool that is not in their toolbox: a finance analyst after list_all_greenhouse_job_openings, a sourcer after list_all_greenhouse_prospect_pools. Have them raise an access request instead of asking a colleague to paste them a key. Request and resolution both land in the log, so policy improves on evidence rather than anecdote.

Route notifications to Slack or email so a broken connection is caught before the Monday pipeline review, and forward the log to Datadog if your security team already works there. The log is eventually consistent, so a row can take a moment to appear. That is normal, not a gap.