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 should:

1. Discover the company, or use an explicit company_id when the account has more than one.
2. Read the pipeline so it knows the stage ids, not just the display names.
3. List positions in the right state, usually published or draft.
4. List candidates for one position.
5. Fetch candidate metadata only for the records that need deeper review.

That keeps the result grounded in the hiring team's structure. It also keeps 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 and optionally include metadata such as 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

Ask:

List our Breezy HR companies, show published positions for the main company, and summarize which roles have candidates waiting in Applied or Interviewing.

The agent can answer by walking the workflow rather than guessing:

1. Get companies and select the right company.
2. Get pipelines and identify the stage ids.
3. Get published positions.
4. For each position that matters, list candidates.
5. Group candidates by stage and return a short recruiting standup.

That is a better fit for a founder or recruiting lead than a raw candidate export. It gives them the operational answer: which roles need attention today?

Example workflow: sourced candidate intake

Ask:

Create a sourced candidate for the sales manager role with this name, email, LinkedIn URL, and source attribution. Return the candidate id and current stage.

The agent needs to find the role, create the candidate under the correct position, preserve source attribution, and return the resulting candidate id. If the candidate is later ready for an interview, it should read the pipeline first and move the candidate using the stage id Breezy returned.

This is the difference between "write to an ATS" and "operate a recruiting workflow." The former is easy to expose and easy to misuse. The latter requires the tool descriptions and skill content to teach the agent how the domain fits together.

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

Start with a read-only pass:

Show me our Breezy HR companies, pipelines, and published positions. Then tell me which candidate queues are empty and which need review.

Then try a targeted candidate workflow:

For the product manager role, list the newest candidates, include metadata for the top three, and draft a follow-up plan grouped by stage.

When you are ready to write:

Add this sourced candidate to the sales manager role, tag them as referral, and return the candidate id.

Open the server page here: Breezy HR MCP server.