Breezy HR with AI: Recruiting Workflows Need Stages, Not Just CRUD

Most ATS automation starts with a shallow question: can an agent create, read, update, and delete candidates?

That is the wrong first question. Recruiting work is not a generic CRUD table. It is a workflow with company boundaries, positions, pipeline stages, candidate metadata, hiring-team notes, and a real audit trail. If the tool surface only says "update candidate," the agent still has to guess which company, which role, which stage, and which action is safe.

We rebuilt the Breezy HR MCP server around the workflow shape instead: discover companies, read pipelines, inspect positions, list candidates, fetch metadata when needed, create or update candidates, move them through stages, and archive positions for cleanup.

The useful object is the pipeline

Breezy HR exposes candidates under positions, and positions live inside companies. That nesting matters.

An agent reviewing candidates for a role should not start by searching every candidate in the account. It starts by picking the right company (an account_id, not a name), reading the pipeline so it knows the stage ids behind "Applied" and "Interviewing", listing the positions in the state that matters (published or draft), pulling candidates for the one position the user actually asked about, and only fetching deeper metadata — notes, scorecards, conversation — for the records that need it.

That keeps every answer anchored to the hiring team's structure. It also stops the agent from making the classic ATS mistake: treating "Applied", "Interviewing", and "Made Offer" as labels instead of workflow state.

What the Breezy HR server can do

The rebuilt server covers the main ATS lifecycle:

• Get companies visible to the connected account.
• Get hiring pipelines and stage ids.
• Get one position or list positions by state.
• Include a position's hiring team when reviewing ownership.
• Create or update positions.
• Set position state to published, draft, closed, or archived.
• List candidates for a position with pagination and sort order.
• Return one candidate, optionally with associated notes, documents, conversation, references, questionnaires, and scorecards.
• Create or update candidates.
• Move candidates between pipeline stages.

The product page has the durable reference for the server: Breezy HR on MCPBundles. This post is the product note for why the surface is shaped that way.

Example workflow: Monday recruiting standup

A founder asks the agent on Monday morning to list the Breezy HR companies, pull published positions for the main company, and summarise which roles have candidates waiting in Applied or Interviewing.

The agent walks the structure: companies, then pipeline stages, then published positions, then candidates per position, grouped by stage. The answer is a one-screen recruiting standup — "Senior Eng has 4 in Interviewing, Sales Manager has 12 in Applied with no movement in 9 days, Designer queue is empty" — and not a raw candidate export.

Example workflow: sourced candidate intake

A recruiter asks the agent to create a sourced candidate for the sales manager role from a name, email, LinkedIn URL, and source attribution, and return the candidate id and current stage.

The agent finds the position, creates the candidate under it, preserves the source attribution Breezy distinguishes (sourced vs applied vs referral), and reads back the resulting candidate id. When that candidate is ready for an interview a few days later, the same agent reads the pipeline again first and moves the candidate using the stage id Breezy returned, not the display label.

That is the gap between "write to an ATS" and operating a recruiting workflow. The first is easy to expose and easy to misuse. The second is what the tool descriptions and skill content on this server are tuned for.

The authentication detail matters too

Breezy's documented API uses an access token in the Authorization header, but the sandbox flow we verified obtains that token by signing in with account email and password. We did not model that as a fake static API key.

MCPBundles stores the email and password as encrypted credential fields, signs in server-side to mint the short-lived token, and injects the token into each Breezy request. The agent never sees the password or token. It just sees the Breezy tools and their schemas.

That keeps the user-facing setup honest and the tool calls normal.

Safe writes and cleanup

The server includes write paths because recruiting automation is not very useful if it can only read:

• Create/update positions.
• Create/update candidates.
• Move candidates between stages.
• Archive positions.

It does not invent a candidate delete tool. The public Breezy HR API documentation we used does not expose a candidate delete endpoint. So the server does not pretend deletion exists. Workflow cleanup uses documented state changes: archive positions, close positions, or move candidates to stages such as disqualified.

That is the rule we want across MCP servers: expose the useful lifecycle, but do not fill gaps with guessed operations.

What to try first

Three prompts in order of risk.

The read-only pass: ask the agent to show your Breezy HR companies, pipelines, and published positions, then flag which candidate queues are empty and which look stuck. Stuck queues are the early-warning signal — they tell you which roles you are about to lose this week.

The targeted candidate sweep: ask the agent to take one role (say, "product manager"), list the newest candidates, include metadata for the top three, and draft a follow-up plan grouped by stage. The output names candidate ids and the stage they need to move to.

The first write: ask the agent to add a sourced candidate to the sales manager role, tag the source as referral, and return the new candidate id. After that, moving them through stages is just one more tool call against a stage id the agent already has.

The product page is at Breezy HR MCP server.