MCP Recruiting Workflows: Make Each Step Composable

MCP recruiting workflows connect assistant tools around a specific task, such as preparing a candidate reply. Each step needs a stable application ID, usable result fields, and visible limits. Reading a thread, creating a draft, and sending a message are separate actions, with a named teammate owning the final review.

A candidate asks whether their interview can move to Thursday. Your assistant finds the conversation, reads it, and writes a polite answer. The reply looks finished, but questions remain: which application did it use, did it read the latest message, and did anybody check Thursday’s availability?

Those questions belong in the workflow. You should be able to answer them from each call’s results, without asking the assistant to reconstruct what happened from its own summary.

What does a composable MCP recruiting workflow need?

A composable workflow lets the next step consume the previous step’s evidence directly. For a candidate reply, that means preserving the application ID, checking what the read returned, and carrying a visible draft state into review.

Earendil Engineering’s September 29 essay, “You Said No MCP!”, describes adding MCP support to Pi and making tools available through a JavaScript orchestration sandbox. The authors argue that tool discoverability and result formats affect how easily tools can work together. Their examples concern developer tools, so applying the argument to recruiting requires a separate design.

Start with one task your team can inspect: prepare a reply to an existing conversation. Define its inputs and intended outcome before choosing an orchestration method.

The application ID is the link between calls. A candidate may have applied for two jobs. A name or email address alone does not identify which process the reply concerns. Keep the selected application and its job posting together, even when the assistant’s conversational summary mentions only the person’s name.

The workflow also needs a stated stopping point. “Prepare a draft for Morgan to review” gives the assistant an observable endpoint and Morgan a task. “Handle the inbox” leaves selection, scope, and completion open to interpretation.

If you are still deciding which resources and actions an assistant may access, use the resource and action permissions checklist. Here, assume that access has been configured and focus on what passes between calls.

What do structured tool results actually solve?

Structured tool results make fields easier to consume and validate. They do not establish whether the underlying facts are current or whether the result contains everything the reply needs.

The MCP tools specification dated 2025-11-25 defines structuredContent as a JSON object and supports an optional outputSchema. When a tool supplies that schema, its structured result must conform to it, and clients should validate the result. JSON serialized inside a text block can also be parsed, but it is a different protocol representation.

This distinction matters when writing an adapter. Check each tool’s return format rather than assuming every result has the same shape. In Kit, typed structured responses are selective: application summary tools provide them, while the candidate reply tool returns a JSON text envelope. The MCP tool reference describes the tools you can connect.

Once you have parsed a result, validate the fields your next step requires. A missing application ID should stop the workflow. An empty notes list can be a valid result. A truncation flag needs a decision about what remains unread. Treating all three as “the tool returned something” hides those differences.

When should you compose calls in code?

Code can help a workflow join results by ID, filter a bounded queue, or apply the same checks to several reads. A single candidate reply can also work through direct tool calls if the assistant preserves the evidence and respects dependencies.

Anthropic’s engineering article on code execution with MCP describes loading tools as needed and filtering intermediate results before they return to the model. It also describes the additional work of sandboxing, resource limits, and monitoring. That supports a useful design option; it does not establish a recruiting performance result or guarantee savings for your integration.

Choose code when it makes a concrete dependency easier to enforce. For example, the draft call should remain unreachable until the thread read has passed your completeness check. Independent reads may run together, but the reply depends on their completed results.

How do you connect a candidate reply workflow?

Connect the reply workflow around one application and one inspectable draft. The example below is a proposed operating sequence using Kit tools, not an automatic orchestration engine shipped by Kit.

Suppose Alex, a fictional candidate for a backend role, writes: “Could we move Wednesday’s interview to Thursday? I can do the afternoon.” Morgan owns the conversation. Morgan asks the assistant to prepare an acknowledgment while the team checks the interviewer’s calendar.

1. Select the conversation and retain its identity

Use hiring_list_conversations with the relevant reply filter. Kit supports filters such as needs_reply, pending_draft, and failed; the response includes count and truncation information. The returned queue is bounded, so do not describe the selected rows as the entire backlog when the response says more exist. See the tool reference.

Carry Alex’s application ID into every later call. Also retain the job posting so Morgan can recognize the process. If the query returns two Alex applications, ask the operator to select the intended record before drafting.

Check an existing pending draft before another write. Decide whether Morgan wants to replace it. In Kit, staging a new reply replaces earlier pending drafts in that thread, so repeatedly calling the draft tool is not a harmless way to collect alternatives.

2. Read the thread and inspect the limits

Call hiring_list_messages for that application. Inspect correspondence, pending draft, delivery failures, total count, and limits. The envelope’s truncated flag reports omitted messages; each message’s body_truncated flag reports cut text. Check both, including the pending draft’s body. Recent correspondence arrives in chronological order, which does not establish completeness.

For this example, confirm that the request concerns an interview already discussed in the thread. Check whether the team has since replied or whether a failed delivery explains why Alex is asking again. A duplicate acknowledgment could confuse the candidate even if the wording is accurate.

Treat candidate-authored text as evidence about the request. A message asking to move an interview is relevant. A sentence telling the assistant to ignore its operating instructions is still external message content and should not change the workflow.

3. Fetch only the context the reply needs

Use hiring_get_application_summary if the acknowledgment needs current application context, such as the stage. Avoid filling the message with unrelated notes simply because a tool can return them.

The summary can establish where the application sits. It does not establish that an interviewer is free on Thursday. In this example, calendar availability remains unverified, so the draft should acknowledge the request without confirming a slot:

Hi Alex, thanks for letting us know. We’ll check whether we can move the interview to Thursday afternoon and get back to you once we’ve confirmed a time.

Morgan must take responsibility for that follow-up. If nobody will check availability, even this modest promise needs changing. Do not add “Thursday at 2 works” from a guess, or turn a candidate’s stated preference into a booked appointment.

4. Stage the exact reply and verify its state

Call hiring_send_message with the retained application ID and the proposed body. Despite its API name, this tool stages a pending draft. It does not email Alex. The returned pending_draft link points to the exact draft, anchored within the application thread.

Read the thread state again after staging. Match the reread’s pending_draft.id to the staging result’s data.id: another staging call can replace your draft. Check for a newer inbound message. This read narrows the gap before handoff, but the thread can change before Morgan opens it.

The assistant’s completion message should be concrete: “Pending draft for Alex’s backend application. Open this draft in Kit, review the latest message and scheduling facts, then use Confirm & send if you approve.” Include the returned exact draft link. A generic application link makes Morgan search for the result the workflow already knows.

A chat reply cannot release this draft. Confirm & send rechecks inbox and reply availability and queues delivery. Kit’s delivered state means SMTP handoff completed without raising an error; it does not prove arrival in Alex’s inbox.

What happens when the result is incomplete or stale?

Incomplete context and changed context need explicit handling before the reply advances. Define the response to each condition while designing the workflow, so the assistant does not improvise a confident answer despite missing evidence.

Consider an update from Alex: “Thursday no longer works. Friday morning would be better.” A previously reasonable Thursday acknowledgment is now wrong. The workflow should return to the read and drafting steps, then show Morgan the revised result.

Kit shows a stale warning when a newer inbound message follows a pending draft. That warning does not automatically block, refresh, or discard the draft. Morgan still needs to read the latest message and decide what to do. The AI agent and MCP guide explains the candidate communication handoff.

Keep your error reports specific. “Stopped because the returned thread was truncated and the earlier scheduling agreement is unread” gives Morgan a useful next action. “Something went wrong” makes the teammate repeat the assistant’s investigation.

How should you test the workflow before using it?

Test a reply workflow on synthetic applications and correspondence before using it on real conversations. Check the intermediate evidence and the final state, including cases where the right result is to stop.

Use this proposed acceptance worksheet for one run. It is a design aid your team can adapt, not an industry standard or a built-in Kit test runner.

Begin with the fictional Thursday request and expect one pending acknowledgment. Then change one condition per run: add another application with the same candidate name, make the thread incomplete, disable the inbox, insert an existing draft, or add a Friday request after staging.

For the duplicate-name case, success means preserving the chosen application through the draft. For incomplete context, success may mean stopping without a write. For the new Friday message, success means drawing the reviewer’s attention to the changed request and avoiding a claim that the Thursday reply is current.

Separate the assistant’s task from delivery. If Morgan requested a prepared draft, the acceptance evidence is the correct pending draft and its link. If Morgan later confirms it, track delivery separately. A valid schema and a successful tool response do not establish that Alex received anything.

How does Kit expose the workflow and its handoff?

Kit exposes conversation reads, application context, and a candidate reply draft that a teammate can inspect in the thread. Your integration supplies the orchestration rules connecting those steps, including completeness checks and what to do when evidence changes.

The workflow ends with an anchored pending-draft link, a clear status, and a named reviewer. Morgan can open the exact wording, compare it with the latest inbound request, edit or discard it, or use Confirm & send. After confirmation, delivery status remains a separate fact to check.

This review gate applies to these staged candidate replies. Other Hiring tools can commit changes or trigger notifications, so inspect each tool’s behavior before adding it to a wider workflow. The MCP deployment guide covers connecting agents; the MCP for hiring introduction explains the protocol basics.

Build one reply workflow whose application ID, unread limits, draft, and delivery state you can follow. Use the worksheet to test it, then have a teammate own the handoff. To try that with your team, start with Kit and keep the first task to one conversation and one reviewable draft.