---
title: "How to Build an AI Recruiter Agent with Unified MCP"
img: https://s3.us-east-2.amazonaws.com/unified-article-images/how_to_build_an_ai_recruiter_agent_with_unified_mcp-icon.png
date: 2026-02-20T23:25:00.000Z
tag: Product
description: "Modern SaaS products don't just display candidate data. They screen resumes, update application stages, schedule interviews, send communications, collect..."
url: "https://unified.to/blog/how_to_build_an_ai_recruiter_agent_with_unified_mcp"
---

# How to Build an AI Recruiter Agent with Unified MCP
------
_February 20, 2026_

Modern SaaS products don't just display candidate data. They screen resumes, update application stages, schedule interviews, send communications, collect feedback, and create follow-up tasks. If you're embedding AI into a recruiting workflow, your agent must read and write across ATS, Calendar, Messaging, HR, and Task systems — safely and in real time — without building and maintaining each integration separately.


This is where [Unified [MCP](/mcp)](/mcp) comes in.


Unified's category APIs provide normalized, real-time access to ATS, Calendar & Meetings, Messaging, HR & Directory, and Task Management systems. Unified MCP allows LLMs to call those operations as structured tools.


This guide explains how to architect a production-safe AI recruiter agent using Unified MCP, while respecting provider variability, [rate limits](/docs/reference/rate_limits#rate-limits), tool limits, and PII boundaries.


## Recruiter Agent Architecture


A recruiter agent typically performs four stages:

1. Candidate screening
2. Interview scheduling
3. Candidate communication
4. Post-interview evaluation

Execution model:


Trigger (webhook or user action) → LLM reasoning → MCP tool calls → Unified API → Source systems


Unified MCP executes structured tool calls. It does not deliver events. Webhooks (native or virtual) may trigger the agent, but MCP performs the reads and writes.


All tool calls are real-time pass-through requests to the underlying provider. No customer data is cached or stored.


## Stage 1: Candidate Screening


This stage requires read-only access to ATS data.


Minimal tools:

- ats-candidate:list → GET /ats/{connection_id}/candidate
- ats-candidate:retrieve → GET /ats/{connection_id}/candidate/{id}
- ats-document:list → GET /ats/{connection_id}/document
- ats-document:retrieve → GET /ats/{connection_id}/document/{id}

ATS documents include both `document_url` and `document_data` in the unified schema. Documents can be filtered by `type` (e.g., RESUME, COVER_LETTER). Provider support for these fields varies, so agents must handle missing URLs or payloads gracefully.


Tool count: 4


Groq (10) → safe


OpenAI (20) → safe


Cohere (50) → safe


No writes are required at this stage.


## Stage 2: Interview Scheduling


This stage requires Calendar + HR + optional Messaging tools.


Minimal tools:

- calendar-busy:list → GET /calendar/{connection_id}/busy
- calendar-event:create → POST /calendar/{connection_id}/event
- hr-employee:list → GET /hris/{connection_id}/employee
- messaging-message:create → POST /messaging/{connection_id}/message

Calendar supports full event CRUD in the unified model, including recurrence, attendee lists, RSVP status, and cancellation via status or delete. Provider capability varies: some providers are read-only for events, and some lack busy endpoints. The agent must check provider support before attempting writes.


HR & Directory provides full CRUD for employees and groups. Manager relationships are fields (`manager_id`, `manager_ids`) — there is no separate Manager object. Employee roles are enum values inside `employee_roles`.


Messaging support depends on provider:

- Slack supports create/update/delete but only for messages authored by the bot/user.
- Teams supports create and limited update; delete is not supported via Unified.
- Gmail allows send and delete but cannot edit sent content.
- Outlook allows editing drafts; sent message body/subject are immutable.

Tool count: 4


Groq → safe


OpenAI → safe


Cohere → safe


## Stage 3: Candidate Communication


Minimal tool:

- messaging-message:create → POST /messaging/{connection_id}/message

Provider restrictions apply (see above). Attachments are supported for Slack, Gmail, and Outlook; Teams attachments are read-only in Unified.


Tool count: 1


Safe for all models.


## Stage 4: Post-Interview Evaluation


This stage writes back into ATS and optionally creates tasks.


Minimal tools:

- ats-candidate:update → PUT /ats/{connection_id}/candidate/{id}
- ats-application:update → PUT /ats/{connection_id}/application/{id}
- ats-scorecard:create → POST /ats/{connection_id}/scorecard
- ats-scorecard:update → PUT /ats/{connection_id}/scorecard/{id}
- task-task:create → POST /task/{connection_id}/task

ATS supports full CRUD for Candidate, Job, Application, Interview, Document, and Scorecard objects. Stage/ApplicationStatus is read-only (list only). Provider variability applies: some ATS platforms expose scorecards as read-only; some treat stage transitions differently; some do not provide structured interview objects.


Task Management exposes Project, Task, Comment, and Change objects. Change is read-only (audit history). Task writes vary by provider: some do not allow status updates; some require status on write; some restrict deletion semantics.


Tool count: 5


Groq → safe


OpenAI → safe


Cohere → safe


## Combined Tool Surface


If you expose all ATS (37 tools), Calendar (23), Messaging (8), and Task (17) tools simultaneously, you reach 89 tools. This exceeds Groq (10), OpenAI (20), and Cohere (50) limits.


Unified MCP documentation states:

- Groq models can only handle 10 tools.
- Most OpenAI models can handle 20 tools.
- Cohere models can handle 50 tools.

Tool restriction is mandatory.


Use:

- `permissions` → limit allowed operations
- `tools` → allowlist specific tool IDs
- `defer_tools` → defer loading where supported

Each recruiter workflow stage above remains within limits when configured independently.


## Provider Variability Matters


Recruiter agents must not assume uniform capabilities.


Examples documented in Unified sources:

- Some ATS providers do not allow writing `status`.
- Some do not support scorecard writes.
- Resume retrieval varies by provider.
- Task status writes vary across platforms.
- Comment editing/deletion varies by provider.
- Deletion events may not be emitted by virtual webhooks.

Unified normalizes schema, not provider behavior.


Agents must handle validation failures and permission mismatches safely.


## Rate Limits and Webhooks


Provider rate limits apply to all real-time calls. List endpoints return a maximum of 100 records per page. Filters like `updated_gte`, `project_id`, and `status` should be used to reduce volume. Exponential backoff with jitter should be implemented for 429 responses.


Native webhooks are available for certain ATS, Calendar, Messaging, and Task integrations. Virtual webhooks provide polling-based change detection when native push events are unavailable. Virtual webhooks emit created and updated events; deletion events depend on provider support.


Webhooks trigger the agent. MCP executes actions.


## Compliance and PII Controls


Unified uses a zero-storage, stateless architecture. API calls are real-time pass-through. Customer data is not stored at rest; only minimal operational metadata is retained and encrypted.


The `hide_sensitive` parameter removes sensitive fields (e.g., names, emails, telephone numbers) from MCP responses.


API call logs are retained for 60 days. Regional routing (US/EU/AU) supports data residency requirements. Access is controlled via scoped API keys, SAML/OIDC SSO, and IP allow-listing.


MCP tool exposure should be limited to only the required operations for the recruiter workflow.


## API vs MCP for Recruiter Agents


Use Unified APIs directly when:

- Your backend orchestrates screening logic.
- You batch-process resumes.
- You build analytics dashboards.
- You control deterministic stage transitions.

Use Unified MCP when:

- The LLM decides which candidate to advance.
- The agent schedules interviews.
- The model writes scorecards.
- The assistant posts updates or creates follow-up tasks.

Execution path remains:


User → LLM → Tool call → Unified API → Source system


The only difference is who selects the action.


## Production Checklist


A production-ready recruiter agent must:

- Restrict tool surface via `permissions` or `tools`.
- Avoid exposing all categories at once.
- Handle provider-specific write restrictions.
- Implement idempotency for webhook processing.
- Respect provider rate limits and pagination.
- Use `hide_sensitive` when PII redaction is required.
- Design human-approval checkpoints for high-risk actions.

When configured this way, Unified MCP enables real-time, agent-executable recruiting workflows across ATS, Calendar, Messaging, HR, and Task systems — without building per-provider integrations or storing customer data.


[→ Start your 30-day free trial](https://app.unified.to/login)


[→ Book a demo](https://calendly.com/d/cph9-g8n-jzg/connect-with-unified)