Primary keyword: Bullhorn MCP server
If you want help scoping and building this securely, book a free consulting call.
A Bullhorn MCP server is a small, secure “tool gateway” that sits between an AI assistant (like Claude or ChatGPT) and Bullhorn’s API. Instead of giving an AI raw API access, you expose a limited set of read-only tools (for example: get placement by ID, search companies, list recent activities) and enforce authentication, rate limits, and field-level permissions in one place.
This lets your team query Bullhorn data in natural language—without turning Bullhorn into an open-ended AI plugin.
Why teams are moving from Zapier-heavy Bullhorn workflows to MCP
Many Bullhorn teams start with Zapier for practical reasons: it's fast to ship and easy for non-developers to maintain. But as usage grows, you often hit three problems:
- Too many tasks per workflow: a “simple” process can require multiple Bullhorn calls (placement → company → owner → activities), which drives up Zapier task volume.
- Token/auth edge cases: Bullhorn auth flows can be finicky, and “refresh early / expired token” issues can cause intermittent failures.
- AI projects don’t fit the Zapier model: AI assistants need a tool interface (query + retrieve + summarize), not a rigid trigger/action sequence.
An MCP server doesn’t replace Zapier—it complements it. Keep Zapier for event-driven automation (syncs, notifications, document generation), and use MCP for interactive AI querying and controlled actions.
What MCP is (plain English)
MCP (Model Context Protocol) is a standard way for an AI assistant to call tools.
Think of it like this:
- Zapier = a workflow builder for people
- MCP server = a workflow/tool interface for AI assistants
Your MCP server publishes a list of tools (functions) the AI is allowed to use. Each tool has:
- a name (like
get_placement) - an input schema (what parameters are allowed)
- a response shape (what data comes back)
- guardrails (auth, logging, rate limiting, read-only mode, etc.)
What MCP is
A practical “starter” architecture looks like:
- AI client (Claude/ChatGPT) sends a tool call request.
- MCP server validates the request:
- user identity / access scope
- allowed tool name
- safe parameter shapes (no arbitrary query strings unless you deliberately allow it)
- MCP server calls Bullhorn REST API with your chosen auth pattern.
- MCP server returns a sanitized response (only the fields you want the AI to see).
Where to host it
Many teams host MCP servers on a lightweight platform (for example, Heroku or similar). The key requirement is reliability, monitoring/logging, and secrets management—not raw compute.
The most important decision: tool scoping (what you expose first)
The fastest way to build an unsafe MCP server is to expose “generic API passthrough” tools.
Start with specific, read-only tools that map to real user questions.
Recommended Phase 1 (read-only)
Pick 5–10 tools that answer 80% of questions:
- Placements
- Get placement by ID
- Search placements by date range / status
- Get placement emails / contact info fields you already store
- Companies (Client Corporations)
- Get company summary (name, status, owner)
- List open job orders for a company
- Activities/Notes
- List recent activities for a candidate/contact/company
- Pull activity text (email subjects, note bodies) for summarization
These tools are enough to enable prompts like:
- “Summarize what’s been happening with this company over the last 2 weeks.”
- “Find placements ending this week and show risk flags.”
- “What did we last email this candidate about?”
Recommended Phase 2 (limited write actions)
Only after read-only is stable:
- Create an activity note (“AI summary note”)
- Update a single safe field (for example: internal tags)
- Create a follow-up task for an assigned owner
Authentication and token handling (what to do in practice)
Bullhorn typically requires OAuth-style tokens. In an MCP context you have two common patterns:
Pattern A: server-owned integration user (simplest)
- MCP server authenticates to Bullhorn using a dedicated “integration” Bullhorn user.
- You enforce authorization inside your server (who can request what).
Best for: internal AI assistants where the MCP server is the main governance layer.
Pattern B: user-delegated tokens (best for strict per-user access)
- Each human user authorizes Bullhorn access.
- MCP server stores encrypted tokens per user and refreshes them.
Best for: environments where Bullhorn access varies heavily per user.
Practical safeguards either way
- Encrypt tokens at rest and rotate secrets.
- Implement automatic refresh with backoff.
- Return clear, actionable errors to the AI client (so it doesn’t “guess” and retry dangerously).
Rate limits, logging, and safety controls
A production MCP server should include:
- Rate limiting per tool (and ideally per user)
- Request logging (tool name + parameters, with sensitive values redacted)
- Response logging (high-level, or hashes—avoid storing sensitive payloads if you don’t need to)
- Replay protection for sensitive write actions
- Read-only mode switch so you can disable writes instantly
When to use Power Automate vs Zapier (especially for Microsoft-side steps)
If your process touches Microsoft tools (SharePoint, Outlook, Teams), Power Automate can be a strong way to reduce Zapier task load.
A useful split is:
- Use Power Automate for Microsoft-native actions (date-based SharePoint list updates, reminders, Teams notifications).
- Use Zapier for cross-app orchestration when you need speed and broader app coverage.
- Use your Bullhorn MCP server when the requirement is “let AI query Bullhorn and summarize/decide,” not “run a deterministic workflow.”
Example: a phased rollout plan
Week 1: define use cases + tool list
- Pick 10 real questions recruiters/ops ask weekly
- Translate each into 1 tool (not a generic query)
Week 2: implement read-only MCP tools
- Placements + companies + activities
- Add logging, rate limiting, and field sanitization
Week 3: test with real prompts (and lock down)
- Validate accuracy and access controls
- Add guardrails for prompt injection (tools never accept arbitrary “SQL-like” queries unless explicitly allowed)
Week 4+: add one write tool at a time
- Start with “create internal note” and “create follow-up task”
Common mistakes (and how to avoid them)
- Exposing an unrestricted API tool (“call_any_endpoint”) → start specific, then expand.
- Skipping monitoring → add tool-level logs from day one.
- Going write-enabled too early → ship read-only first.
- Letting the AI see too much → sanitize fields; only return what’s needed.
Get help building your Bullhorn MCP server
Building a Bullhorn MCP server the right way — read-only first, properly scoped, with auth and logging in place — takes upfront design that pays off fast. If you want help scoping and shipping it safely, book a discovery call with Connex and we'll walk through your use cases and tool list together.
