The July 2026 MCP Audit: 2 ATS Vendors Shipped Real Servers. Source Both.
A July 2026 audit found only Ashby and 100Hires ship first-party recruiter MCP servers. Here is how to source the tiny pool of engineers who built them.
A July 2026 audit of recruiting tech vendors landed with a quiet thud: only two tools ship first-party, recruiter-facing MCP servers. Ashby, in beta since June 2026, and 100Hires, whose native ChatGPT app runs on a 130-tool MCP server. Everyone else labeled "MCP-compatible" is running a Zapier wrapper, which is an integration two hops removed from the model.
That finding is a buyer trap for procurement, but it is also a sourcing map. The engineers who have actually shipped agent-native ATS plumbing in production are a sub-hundred-person population, and most of them are not searchable by the filters your ATS gives you.
What the audit actually said
The audit is narrow on purpose. It scores vendors on whether they host the MCP endpoint themselves, whether authentication is per-user OAuth, and whether the tool surface is designed for autonomous callers rather than developers clicking through a UI. On those criteria, exactly two ATS vendors pass.
Ashby announced MCP at Ashby One in San Francisco on May 7, 2026, alongside Custom Agents, Ashby Assistant, and Scheduling Agents. The beta opened in June. Ashby's own framing is that customers can expose live recruiting context to MCP-compatible AI clients (ChatGPT, Claude, Cursor, and others) without building custom middleware. Users connect through OAuth, and connected clients can only access data and actions that user is already allowed to touch in Ashby. No shared service account. No parallel permission model.
100Hires took a different route: an AI-native ATS whose MCP server exposes 130 tools across 22 categories of recruiting data (candidates, jobs, applications, interviews). Auth is OAuth 2.1 with Dynamic Client Registration, PKCE, one-hour access tokens, refresh tokens, per-user token binding, and a Connected AI Clients admin panel with revoke. That acronym soup is the actual tell. If a vendor cannot produce that list, they do not have a production MCP server.
ZipRecruiter's much-covered Claude integration is job-seeker-facing search, which is a different problem entirely. StackOne aggregates 200+ integrations behind a single MCP interface and earned a Gartner Cool Vendor nod in HR Technology in 2025, but that is an aggregator layer, not a first-party ATS. The scarcity being described is specifically the ATS layer.
Why "MCP-compatible" is the new "AI-powered"
Read a recruiting vendor's landing page in 2026 and every third bullet says "MCP-compatible." Most of them mean something like: we have a Zapier action, and Zapier has an MCP bridge, so technically an agent can trigger our webhook. That is not what buyers want when they say they want agentic AI recruiting.
There is one question that separates the real from the theatrical: does the vendor host the MCP endpoint, and does it do OAuth per-user or a shared service token? If the answer is "we use Zapier," the vendor is not building MCP infrastructure. They are renting it, badly, and inheriting the exact latency and permissioning problems that MCP was designed to solve.
Tool count is marketing. Auth model is the tell. Skim vendor sheets for OAuth 2.1, PKCE, and per-user token binding, not for the word "AI."
That distinction matters for your AI recruiting stack 2026 procurement, but it matters more for hiring. Because if you are an engineering leader trying to build something like Ashby's or 100Hires' MCP server inside your own product, you need engineers who have already thought about the auth model, the tool schema, and the error contracts. Those engineers are rare, and most of them do not have "Model Context Protocol" anywhere on their LinkedIn.
The MCP engineer profile, in specifics
MCP was introduced by Anthropic in November 2024, created by David Soria Parra and Justin Spahr-Summers. It was donated to the Linux Foundation in December 2025 as part of the newly formed Agentic AI Foundation. The entire specialty is less than two years old. That constrains where the talent can come from.
The engineers who ship production MCP servers are not general backend engineers who read a spec last weekend. LeadDev's guidance is direct: design for agents, not developers. Nested hierarchies and verbose responses that work fine in a REST client break down when the caller is autonomous. Agent-driven traffic is unpredictable. Tools need to be high-intent, single-call, and self-correcting. REST API veterans do not automatically transfer.
When you interview for this role, interview for three things:
- Tool schema design. Can they articulate why an MCP tool should be a single high-intent action rather than a thin REST proxy?
- Error contracts. How does the tool tell an autonomous agent that it failed in a way that lets the agent recover without human intervention?
- Auth model. Can they walk through OAuth 2.1 with DCR and PKCE from memory, and explain why per-user token binding is not optional?
General backend chops are table stakes. The differentiators are the three above, plus a public artifact you can read.
The GitHub-first shortlist nobody is searching
Here is the sourcing insight that matters. The engineers who have shipped production-shaped MCP servers for recruiting are a GitHub-first population, not a LinkedIn-first one. Standard skill-tag searches on professional-network data return effectively zero matches for "Model Context Protocol" at recruiting-tech companies. The pool is too small and too new for the taxonomies to have caught up.
But the pool has self-declared. Unofficial Ashby MCP servers already exist on GitHub, npm, and PulseMCP: nxrobins/ashby-mcp, antonber/ashby-mcp, lightninglabs/ashby-mcp, dewierwan/ashby-mcp, PlenishAI. These are engineers who wrote a production-shaped MCP server on nights and weekends before Ashby shipped one. That is a stronger signal than any resume keyword.
nxrobins built a stdio plus HTTP/SSE Ashby MCP server that runs on Render, explicitly designed for re-engagement campaigns and silver-medalist workflows. That is a recruiter's brain in an engineer's body. Lightning Labs shipped a Go MCP server exposing 19 Ashby tools over stdio. Lightning Labs is a Bitcoin infrastructure company, which tells you something important: production-grade backend engineers with MCP experience live in adjacent verticals, not just recruiting SaaS. They solved their own hiring problem and left the code on GitHub.
This is exactly the kind of query that traditional sourcing chokes on, which is why we built Refolk: you describe the person in plain English ("engineers who have published an MCP server that wraps an ATS or HRIS API, ideally with OAuth 2.1") and you get a ranked shortlist across GitHub, LinkedIn, and the open web, not a keyword match on a skill you know nobody has tagged yet.
Named practitioners, on record
Two Ashby names are quotable and searchable from the May 7, 2026 launch coverage. Max Rodewald, Engineer at Ashby, was on record about the agents work in the PRNewswire release. Anika Zaman, AI Product Manager at Ashby, gave the "API layer designed for AI" framing at Ashby One. Neither of them is likely to move, but the engineers around them are the second-degree shortlist. This is standard practice for sourcing AI infra engineers: name the on-record principals, then map their teams.
The 100Hires side is harder because the company has been quieter about individual attribution. That is a common pattern with AI-native ATS startups: the marketing surface names the product, not the engineers. Refolk's GitHub and open-web indexing tends to surface the commit authors on the public parts of the codebase (SDKs, example clients, docs repos) even when the company itself does not publish an engineering roster.
Why the traditional sourcing filters break here
The instinct is to search "Model Context Protocol" as a skill on a professional network and filter by ATS employers. That returns essentially nothing, and the nothing is misleading. The skill exists; the tag does not.
The filter that actually works is a compound one:
- Current or past engineer at Ashby, 100Hires, Greenhouse, Lever, Ashby-integration vendors, or an HRIS with public API work.
- A public MCP repo, or an MCP-adjacent artifact (an agent tool schema, an OAuth 2.1 DCR implementation, an SSE server for LLM tool calls).
- Backend or platform history with authentication infrastructure, not just CRUD.
That is three signals AND'd together across GitHub, LinkedIn, and the open web. It is exactly the query shape that plain-English sourcing handles well and boolean strings handle badly. Ask Refolk for "backend engineers who built OAuth 2.1 auth flows at an ATS or HRIS and have a public MCP or agent-tools repo" and you get the compound intersection ranked, not a keyword salad you have to hand-dedupe.
What to do this week
If you are an engineering leader building for the agentic AI recruiting wave, three moves:
Read the community Ashby MCP repos. All five of them. The code tells you who understands tool schema design and who is proxying REST. Reach out to the authors. Most of them are not job-searching, which is why the outreach has to be about the code they already wrote, not the role you have open.
Interview for the three differentiators. Tool schema design, error contracts, auth model. General backend interviews will let through people who cannot ship this.
Stop using "MCP" as a skill filter. Use it as a search term against public artifacts. The people you want have GitHub before they have LinkedIn skills tagged.
And if you are a buyer, ask the one question. Does the vendor host the MCP endpoint? Does auth run OAuth per-user? If the answer is a Zapier reference, the vendor is not on your MCP recruiting tools shortlist. As of July 2026, that shortlist is two names long.
FAQ
Is the "only two" claim really accurate?
The honest framing is "first-party, recruiter-facing MCP servers from ATS vendors themselves." Community Ashby MCPs exist on GitHub. Payroll-adjacent MCPs exist (Gusto, Check). StackOne aggregates 200+ integrations behind a single MCP interface. The scarcity is specifically the first-party ATS layer, and there Ashby and 100Hires are it as of July 2026.
Why does the auth model matter more than the tool count?
Because autonomous agents inherit whatever permission model the MCP server uses. A shared service token means every agent action runs as a super-user, which is a compliance and audit nightmare. Per-user OAuth 2.1 with PKCE and per-user token binding means the agent can only do what the human it represents could already do. That is the difference between a demo and a production system, and it is the difference between a vendor you can actually deploy and one you cannot.
How do I find engineers with MCP experience if the skill tag returns zero?
Filter on artifacts, not tags. A public MCP repo, an agent tool schema, an OAuth 2.1 implementation with DCR, or an SSE server for LLM tool calls are all stronger signals than a self-reported skill. Plain-English sourcing tools that index GitHub alongside LinkedIn will surface the compound intersection; boolean keyword searches on a single network will not.
Should we wait for the MCP talent pool to grow?
The pool is growing (9,400+ public servers in 18 months, 78% enterprise adoption reported across AI teams), but demand is growing faster. Gartner has 82% of HR leaders deploying agentic AI by mid-2026 and 52% of talent leaders adding autonomous agents this year. If you wait for the taxonomy to catch up, you will be hiring against every other buyer in the audit. The window is now, and it favors teams that source on artifacts.