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 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, tool limits, and PII boundaries.
Recruiter Agent Architecture
A recruiter agent typically performs four stages:
- Candidate screening
- Interview scheduling
- Candidate communication
- 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 operationstools→ allowlist specific tool IDsdefer_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
permissionsortools. - Avoid exposing all categories at once.
- Handle provider-specific write restrictions.
- Implement idempotency for webhook processing.
- Respect provider rate limits and pagination.
- Use
hide_sensitivewhen 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.