MCP and the Agent Layer That Is Coming to Recruiting

This is Part 3 of an earlier post on AI Fit Engine service that I built to help recruiters evaluate my fit against any job description based on 70 pages of my professional experience.

Part 3: MCP and the Agent Layer That Is Coming

Why Add an MCP Server

A day after launching the web tool, I added a second way to access it. The site now runs an MCP server, which stands for Model Context Protocol (MCP). This means a recruiter using Claude Desktop, Cursor, or any other MCP-compatible client can connect directly to chat.kostenko.com and query my professional knowledge base without ever opening a browser.

As of March 2026, I guess fewer than 1% of recruiters will use this. That is fine. This is not about today's adoption curve. It is about where the tooling is heading.

What MCP Actually Does

For those unfamiliar, MCP is an open protocol that lets AI assistants connect to external tools and data sources. Some call is the USB-C for agents. Think of it the way your browser connects to websites. The browser does not know what content it will find. It just knows how to ask for it. MCP works the same way for AI clients. A recruiter running Claude Desktop can point it at a server and suddenly their AI assistant knows how to call specific tools, in this case tools that evaluate a candidate's fit for a role.

The server I built exposes three tools. One takes a full job description and returns a scored fit analysis. One handles follow-up questions in the context of a specific JD. One returns a quick overview of my background (no LLM calls) so the recruiter can decide if the full analysis is even worth running. The same knowledge base, the same scoring logic, the same evidence grounding. Just a different interface.

The Setup Page

I added a dedicated page at /usemcp with everything a recruiter needs to connect. It walks through the Claude Desktop configuration step by step, includes a copyable config snippet, and has a short Loom video showing the setup in under three minutes. For recruiters using other MCP clients, the raw endpoint is documented there as well. The page is passcode-protected the same way the main tool is (contact me on LinkedIn if you want the code). Same bar to entry, same intent.

Why MCP Before Agents

The recruitment industry is sitting on the edge of a fundamental shift. Right now, most candidate screening runs through application tracking systems. ATS workflows are keyword-driven. They filter on titles, years of experience, degree names, and technology lists. They are efficient at volume and terrible at signal. Every senior technologist has been rejected by a keyword filter that could not parse what they actually do. And in listening to recruiters it sounds like they don't fully understand how the ATS is configured. It's a block box for most of us.

What is coming, and what is already beginning to emerge, is a world where recruiters have their own AI agents. Not chatbots embedded in an ATS. Actual agents that can reason about a candidate's background against the specific requirements of a role. Agents that understand context, weigh tradeoffs, and surface insights that a keyword match never could. I think that by the end of 2026, this will start becoming standard practice simply because the tooling is reaching the point where a recruiter can set up Claude Desktop, connect a few MCP servers, and have a meaningfully better screening workflow than what their ATS provides. I'd like to acknowledge that no recruiter will ever configure an MCP server for each candidate as I've shown in my demo. But a single enterprise add-on can handle this.

What we have now is neat, but that is still the near term. The longer trajectory is more interesting.

Eventually every job description will have its own agent. Not a static posting on a job board. A live agent that understands the role, the team, the hiring manager's priorities, and the tradeoffs they are willing to make. On the other side, candidates will have their own agents, ones that represent their experience, their preferences, their constraints. Hiring will become a negotiation between agents before a human conversation ever happens. The agents will filter, qualify, and match in ways that are simply not possible when a recruiter is scanning 200 resumes on a Monday morning.

I did not build an agent for this initial use case, and that was deliberate. An agent implies autonomy. It acts, it decides, it negotiates. That makes sense when both sides of the table are instrumented. Right now they are not. A recruiter evaluating whether a candidate is even worth a phone call does not need an autonomous agent. They need a tool they can query when they are ready, on their terms, inside the client they are already using. MCP is exactly the right layer for that. It extends the recruiter's existing AI workflow rather than replacing it.

When both sides are ready, when JDs have agents and candidates have agents and the protocol layer supports structured negotiation, that is when the agent architecture makes sense. That is a different article and a different build. But the MCP server running today is the foundation it will sit on.

What This Means

The web tool at chat.kostenko.com answers the question: does this person fit my role? The MCP server answers the same question but meets the recruiter where they already work. Together they represent something I think every senior technologist should be thinking about. Your professional history is a dataset. The tools to make that dataset queryable, scorable, and accessible through open protocols already exist. The recruiters who adopt these tools first will have a meaningful advantage. The candidates who make their backgrounds machine-readable will be the ones those recruiters find.

Demo

View my MCP server demo.

If you are a recruiter and want to try MCP with my profile, the setup instructions are at chat.kostenko.com/usemcp. If you are a technologist who wants to build your own version, reach out on LinkedIn.