Scoping the First Release of an MCP
Recruiters were already weaving AI assistants into their daily work. Some of our customers had gone further and built their own MCPs between an AI assistant and our applicant tracking system. The team was considering building an official integration and needed to know where to start. I talked to the recruiters who had built their own to learn what pushed them to build, and what they'd want from one we made.
At a glance
Problem. The team wanted to build an AI integration for recruiters but didn't know what capabilities to prioritize for an initial release.
What I did. Interviewed recruiters whose teams had built or bought their own AI solutions, or had asked our account managers about an MCP release. The goal was to understand which stages and tasks recruiters currently use AI for, and what gives them the highest return.
Outcome. The team focused on the hiring-manager experience and reporting. The research showed where recruiters were comfortable using AI, where they wanted it enough to build or buy it themselves, and what they wanted AI to do more of in their workflow.
Research question
Where should we start when building an AI integration for recruiters?
- What AI use cases do recruiters already rely on across the hiring workflow?
- Which areas should the integration prioritize?
- What concerns do they have about using AI in their workflow, and where do they not want AI involved?
Approach
One-on-one interviews with six recruiters from five customer companies, across industries from localization to retail. Every session followed the same five themes, so the answers could be compared side by side.
Decisions that shaped the study
Talk to the people already building
Talking to recruiters who had built their own integration helped us learn what they wanted the tool to do, what their solutions were doing well, and where they could be improved.
Separate what's in use from what's wished for
For every stage I recorded what recruiters actually do with AI today separately from what they'd like it to do.
Tie AI value to known product gaps
Many use cases filled gaps recruiters already complained about, like reporting and finding candidates in the pipeline. Linking the two showed the integration could fix existing pain, not just add something new.
Raise the blockers before the build
Some companies only allow approved tools, and candidate notes are protected data. I flagged these early so the team could plan for them accordingly.
What we learned
AI use is uneven across the workflow. Recruiters lean on AI heavily for writing and interviews, and barely at all for scheduling and offers.
| Stage | Using AI today | Want AI to do |
|---|---|---|
| Intake and job posting | Heavy Transcribe intake calls, draft job descriptions, build candidate profiles | Write job descriptions without switching tools |
| Screening and sourcing | Heavy Match and tag applicants, flag likely fraud, generate search strings | Ranked shortlists with a fit summary; filter fake applications |
| Pipeline | Some Find duplicate candidates, build dynamic lists | Automatic duplicate detection, drafted replies |
| Scheduling | None | Sync outside booking links |
| Interviews | Heavy Interview scripts, transcription, auto-filled scorecards, chasing feedback | Candidate briefs for hiring managers; feedback from chat or email |
| Reporting | Some Answer pipeline questions, pull stage history | Recruiter performance, time to fill, likelihood a role fills |
| Offers | Little Refine offer templates | Nothing yet |
| Support | None | Troubleshoot their own setup |
Two pains stood out. Both came up across companies, and both are places where an integration could do work recruiters were already doing by hand.
- Reporting happens entirely outside the product, in spreadsheets and BI tools.
- Even basic counts mean filing a support ticket.
- Historical and predictive questions take heavy manual digging.
- Feedback arrives late and thin, often just pass or fail.
- Hiring managers skip candidate notes and can't see the pipeline without help.
- Scheduling turns into back-and-forth.
Recruiters want it built in, but trust has to be earned. An official integration would end the copy-paste between tools. But recruiters distrusted community-built code, had seen AI get facts wrong, and were uneasy sending candidates AI-written messages. Some companies also only allow approved tools, and others doubted the cost was worth it.
Conclusion
The research turned an open question, "where do we start?", into a ranked answer. The team focused on the hiring-manager experience and reporting. The findings also echoed my churn research, where reporting was one of the most painful areas for customers. A separate method, with a different group of customers, pointed at the same problem.
How confident to be
- Early adopters, by design.
- Everyone had built their own integration, so they're more AI-forward than a typical recruiter. That made them the right people for "where to start", but their comfort with AI won't hold for every customer.
- Wishes are not commitments.
- The wishlist shows interest, not proof recruiters would use each feature.
What I'd do next
- Test the hiring-manager concepts with hiring managers themselves, not only recruiters.
- Work through compliance with security early, so approved-tools-only customers can adopt it.
- Check the effect on support load. If reporting through the integration works, basic report requests to Support should drop.