Connect Recruitee to ChatGPT: Analyze Interviews and Candidate Notes

If you want to connect Recruitee to ChatGPT so your AI agents can read candidate notes, synthesize interview scorecards, and audit hiring pipelines, you need an integration layer that translates large language model (LLM) intent into REST API requests. If your team uses Claude, check out our guide on connecting Recruitee to Claude or explore our broader architectural overview on connecting Recruitee to AI Agents.

Giving an LLM direct access to your Applicant Tracking System (ATS) is an engineering challenge. You must handle complex pagination, manage access tokens, map highly nested hiring schemas, and protect against destructive data operations. You either spend weeks building, hosting, and maintaining a custom Model Context Protocol (MCP) server, or you use a managed infrastructure layer to handle the boilerplate. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Recruitee, connect it to ChatGPT, and execute complex talent acquisition workflows using natural language.

The Engineering Reality of the Recruitee API

A custom MCP server is a self-hosted API integration layer. While Anthropic's open MCP standard provides a predictable way for models to discover tools, implementing it against vendor-specific APIs is painful. If you decide to build a custom MCP server for Recruitee, your engineering team assumes ownership of the entire API lifecycle.

Here are the specific integration challenges that break standard REST assumptions when working with Recruitee:

The Multi-Tenant Routing Requirement

Recruitee is designed around a multi-tenant architecture where almost all API endpoints are scoped to a specific company. This means you cannot simply call /candidates or /interviews. Every tool your LLM executes must explicitly pass a company_id. If your MCP server does not inject or require this routing parameter natively, the LLM will hallucinate endpoint paths, resulting in 404 Not Found errors across the board. You have to map the company_id requirement into the JSON Schema of every single tool you expose.

Deeply Nested Hiring Schemas

Applicant Tracking Systems do not return flat data. When you request interview results or candidate notes, the payload contains complex nested arrays. An interview result contains a candidate_id, an admin_id, an evaluation object, nested scorecards, and nested attachments. When an LLM requests this data, it expects a predictable structure. If your custom server fails to parse and validate these nested schemas before passing them back to the LLM, the context window fills with unformatted JSON, degrading the model's ability to synthesize the feedback.

Rate Limits and 429 Errors

Recruitee enforces strict rate limits to protect its infrastructure. If an AI agent attempts to audit 500 candidates by firing off concurrent requests for notes and interview results, the ATS will quickly return a 429 Too Many Requests error.

A critical factual note on how Truto handles this: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Recruitee API returns an HTTP 429, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller - whether it is your LangChain agent, ChatGPT, or a custom script - is entirely responsible for reading these headers and implementing its own retry and exponential backoff logic. Your custom server must do the same, or the LLM will assume the tool call succeeded when it actually failed.

The Managed MCP Architecture

Instead of writing and maintaining custom API mapping code, Truto allows you to generate a fully managed MCP server directly from your connected Recruitee instance.

Truto's architecture derives tool definitions dynamically from documentation records and resource schemas. When a client requests the available tools, Truto maps Recruitee's endpoints into a flat input namespace, extracting query parameters and body parameters into a unified JSON Schema that the LLM understands. The execution happens over an authenticated JSON-RPC 2.0 endpoint.

Because the MCP server is hosted on the edge and mapped directly to an integrated account, you do not have to write a single line of OAuth logic, pagination handling, or schema parsing.

Security and Access Control

Exposing your ATS to an LLM requires strict governance. You do not want a prompt injection attack to delete your candidate database. Truto provides several layers of access control on the generated MCP server token:

• Method Filtering: You can restrict the MCP server to specific HTTP methods. Passing config: { methods: ["read"] } ensures the LLM can only execute get and list operations, entirely neutralizing the risk of accidental data deletion or modification.
• Tag Filtering: You can restrict the server to specific functional domains. By applying tags, you can expose only the interviews and notes resources, hiding sensitive resources like billing or offers.
• Time-to-Live (TTL): You can set an expires_at timestamp. Once the timestamp passes, the server URL is automatically invalidated, ensuring temporary agent sessions do not leave permanent backdoors into your ATS.
• Require API Token Auth: By enabling require_api_token_auth, the client must pass a valid Truto API token in the Authorization header. This means possessing the MCP URL alone is not enough; the caller must be an authenticated member of your team.

How to Generate the Recruitee MCP Server

You can create the MCP server either through the Truto dashboard or programmatically via the API.

Method 1: Via the Truto UI

1. Log into your Truto account and navigate to the integrated account page for your Recruitee connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Define your configuration. For a read-only analysis agent, select read methods only.
5. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/abc123xyz...).

Method 2: Via the Truto API

You can dynamically provision MCP servers for your users by sending an authenticated POST request to the Truto API. This is the preferred method for embedding AI agents into your own SaaS product.

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Recruitee Interview Analysis Agent",
    "config": {
      "methods": ["read"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The response will return the configuration along with the secure url needed for the LLM framework.

How to Connect the MCP Server to ChatGPT

Once you have your MCP URL, connecting it to your AI interface takes seconds.

Method A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Enable Developer mode (MCP support requires this flag to be toggled on).
3. Under the MCP servers / Custom connectors section, click to add a new server.
4. Name the connection (e.g., "Recruitee ATS").
5. Paste the Truto MCP URL into the Server URL field and save.
6. ChatGPT will immediately initialize the handshake, downloading the tool definitions for Recruitee.

Method B: Via Manual Config File (SSE Transport)

If you are running a local agent, Claude Desktop, or a custom client that requires a JSON configuration file, you can utilize the standard SSE transport mechanism.

{
  "mcpServers": {
    "recruitee_agent": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/YOUR_SECURE_TOKEN"
      ]
    }
  }
}

If you enabled require_api_token_auth, ensure your client is configured to pass your Truto API token in the request headers.

Hero Tools for Recruitee Analysis

When the LLM connects to the MCP server, it gains access to the underlying proxy API endpoints. Here are the highest-leverage tools available for analyzing candidate pipelines.

list_all_recruitee_interview_results

This tool retrieves all interview results within the ATS. It requires the company_id and returns vital data points including the id, candidate_id, admin_id, the kind of interview, and the detailed evaluation object. This is the core tool used for extracting interviewer feedback.

"Fetch all recent interview results for candidate ID 84729 in our company instance. Extract the evaluation scores and summarize the technical feedback."

list_all_recruitee_notes

Candidates accumulate notes from recruiters and hiring managers throughout the talent lifecycle. This tool requires both company_id and id (the candidate ID) and returns an array of notes containing the admin_id, body, created_at, attachments, and visibility status.

"Retrieve all notes for candidate ID 84729. Filter out any notes that are marked with private visibility, and synthesize the recruiter's initial phone screen impressions."

list_all_recruitee_offer_notes

Offer negotiations often involve back-and-forth discussions stored as offer notes. Requiring company_id and offer_id, this tool returns notes including the text, admin details, timestamps, and nested replies (including reaction data). This is critical for auditing compensation discussions.

"Get the offer notes for offer ID 9921. Summarize the compensation negotiation history and note which admins approved the final salary figures."

list_all_recruitee_admins

ATS records reference admin_id rather than raw user names. To make sense of interview scorecards and notes, the LLM needs to map IDs to real people. This tool lists all admins under a company_id, returning the id, name, email, and role.

"List all admins in our Recruitee instance. Cross-reference the admin IDs from the recent interview results to tell me which specific hiring managers gave a 'Strong Hire' rating."

list_all_recruitee_locations

Hiring often depends on geography. This tool fetches all office locations associated with a company_id. It returns granular data including the country_code, city, full_address, and metadata like active_offers_count and active_requisitions_count.

"List all of our active Recruitee locations in Europe. Check the active requisitions count for each to tell me which office has the highest current hiring volume."

For the complete inventory of available resources, schemas, and custom methods, consult the Recruitee integration page.

Workflows in Action

Giving an LLM access to discrete tools is only the first step. The real value is realized when the model orchestrates these tools into complex, multi-step workflows. Here is how a talent acquisition team uses this integration in production.

The Post-Interview Debrief Synthesizer

After a long day of final-round interviews, a hiring manager wants a consolidated view of how a candidate performed across all panels, without having to click through multiple screens in the ATS.

"We just finished the final rounds for the Senior Engineer role. For candidate ID 55812 in company 9021, pull all of their interview results and general notes. Map the evaluator IDs to actual team member names. Give me a 3-paragraph summary of their strengths, any red flags mentioned in the notes, and the final consensus on whether we should move to an offer."

Execution Steps:

1. The agent calls list_all_recruitee_interview_results passing company_id=9021 and filtering for the specific candidate to retrieve the evaluation scores.
2. The agent calls list_all_recruitee_notes to pull the unstructured recruiter feedback.
3. The agent calls list_all_recruitee_admins to retrieve the directory, mapping the admin_id from the previous payloads to the actual names of the engineering managers.
4. The LLM synthesizes the JSON payloads into a formatted markdown debrief document, highlighting the consensus and surfacing any contradictory feedback between interviewers.

The Offer Approval Audit

Talent Ops needs to verify that all recent engineering offers went through the proper approval channels and that no out-of-band salary promises were made in the notes.

"Audit offer ID 7734 for company 9021. Pull the offer notes and the nested replies. Identify the hiring manager who approved the equity grant, and confirm there are no unresolved objections in the thread."

Execution Steps:

1. The agent executes list_all_recruitee_offer_notes passing the offer_id to retrieve the conversation thread, including all nested replies.
2. The agent executes list_all_recruitee_admins to cross-reference the IDs in the thread.
3. The LLM reads through the chronological text bodies, isolates the messages explicitly approving the equity grant, verifies the identity of the approver, and reports back that the offer is clear for delivery.

Handling Rate Limits in Agentic Workflows

When executing multi-step workflows like the audits above, AI agents can execute operations faster than the Recruitee API allows. Because Truto acts as a transparent proxy for rate limits, your agent architecture must be resilient.

If the LLM issues a call to list_all_recruitee_notes and receives a tool execution error indicating an HTTP 429 status, the system prompt must instruct the agent to halt. The underlying HTTP client should intercept the response, read the ratelimit-reset header provided by Truto, wait the required number of seconds, and automatically retry the tool invocation. Failing to implement this at the client level will result in the LLM hallucinating the contents of the missing notes.

Architecting for Scale

Connecting Recruitee to ChatGPT via a managed MCP server removes the heavy lifting of API maintenance. By leveraging Truto's dynamic tool generation, your engineering team can transition from writing point-to-point integration scripts to architecting resilient, autonomous talent acquisition workflows. You maintain strict security via read-only method filtering, ensure data accuracy by mapping real-time API state into the LLM's context window, and avoid the massive technical debt of tracking ATS schema changes.