MCP and recruitment: what the protocol does not solve

It solves a plumbing problem, and that is already a lot: instead of writing one integration per tool and per model, you write one per tool. What MCP does not solve, however, is the main problem of a recruitment agency or an IT services firm, which is that half the systems holding the information do not belong to it.

This article assumes you already know what the protocol is. If you do not, the complete guide published by Cobalt does that job better than I would redo it here, with the definition, the mechanics and the ATS-side use cases. What follows starts at the next step: you have understood, your vendor announces an MCP server, and you are wondering what changes on Monday morning.

What the protocol genuinely solves

We should start there, or the rest reads as disparagement, and that would be wrong.

Before MCP, connecting a tool to a model meant writing code specific both to the tool and to the model. Changing model meant starting again, and we have shown elsewhere that the model an agent runs on is retired every twelve to eighteen months. An integration you had to rewrite every generation was an integration nobody wrote.

The second gain gets less commentary and matters more to an agency: the protocol made it respectable, for an ATS vendor, to hold the idea that its data must be reachable by third parties. For twenty years the dominant strategy in this sector was to make leaving difficult. A vendor publishing an MCP server has taken a commercial decision, not merely a technical one, and it is that decision which concerns you.

The third is the most concrete. An MCP server forces somebody to describe what each tool does, in readable prose, in a file somebody has to write. For many vendors this is the first time what their software allows from the outside has genuinely been documented, and that documentation is often worth more than the protocol that prompted it.

An agency’s problem is not its own ATS, it is its client’s

This is the most expensive gap between how the subject is presented and how this business works.

Almost all the writing on MCP assumes you are connecting your own tools: your ATS, your CRM, your mailbox. For a company hiring for itself, that is accurate. For an agency working on delegation, or an IT services firm placed across several large accounts, a significant share of the work happens elsewhere: the client’s vendor portal, their applicant tracking tool, the shared sheet where they record their feedback, sometimes simply their mailbox.

No protocol decides on a client’s behalf to grant you access. The slow part was never technical: it is contractual, it goes through an IT department that does not know you, and it takes weeks when it succeeds at all. MCP makes the connection trivial once agreement exists, which moves the bottleneck rather than removing it, and it is better to know that before building a plan on it.

The practical consequence is that an agency should separate the two worlds in its thinking. What it owns connects quickly and can be worked deeply. What belongs to the client gets negotiated, is usually limited to reading, and is often handled by cruder means than a protocol: a periodic export, a dedicated address, a deposited file. It is inelegant and it has worked for twenty years.

Connecting grants no rights you did not already have

It seems obvious written down, and yet it is the most widespread implicit expectation.

An agent speaking MCP to your ATS sees exactly what the account used for the connection sees. If that is a technical account created in a hurry with administrator rights, it inherits administrator rights, and the agent becomes a path around every permission you have set. The protocol has no part in that outcome: it carries, it does not arbitrate.

That is why we insist elsewhere that an agent must act with the rights of the person talking to it, and why your ATS’s ability to answer “what is this specific person allowed to see” matters more than the presence of an MCP server. It is one of the five properties that decide what an agent can do inside your ATS, and the one that disqualifies the most software.

The protocol says nothing about what it carries

It faithfully carries contradictory data, and that may be the most useful point in this article.

An agency connecting its ATS, its CRM and a shared spreadsheet to one agent gets an agent that reads all three. It does not get an agent that knows which one is right. Faced with two different statuses for the same candidate, it picks one and writes a coherent, reasoned, wrong answer, faster than a human would have. The connection has accelerated the production of an error that already existed.

So the question to settle before connecting fits in one sentence, and it has nothing to do with the protocol: for the three or four facts the agent will handle, which system prevails. It is a one-meeting decision, it benefits the business even without an agent, and it determines the value of everything that follows.

An MCP server is still a supplier

It holds credentials on your systems and it feeds the model text the model reads as an instruction, which makes it a subcontractor rather than an extension.

We have developed that point elsewhere, with the 2026 security measurements and the three questions to ask before connecting: an MCP server is a supplier, not a connector. I will not redo it here, I recall it because the ease of connection produces exactly the behaviour to guard against. You add five in a quarter, nobody keeps the list, and that list is precisely what an incident asks you to produce within the hour.

For an agency, one point is worth adding: when you connect an MCP server to a client’s data, you are committing that relationship, not only your own. The question “what happens if this supplier is compromised” stops being internal the moment a third party has entrusted you with access.

So should it be a buying criterion?

A signal, yes; a sole criterion, no, and we have written elsewhere why requiring the protocol is not enough to choose an agent.

The phrasing that actually helps in a demo room is more down to earth. Do not ask “do you speak MCP”, which invites a yes. Ask which objects are exposed for writing, whether your custom fields are among them, how a specific person’s permissions are respected, and whether there is a way to re-read everything that changed since a given date. A vendor answering those four precisely has done the work, whether it exposes an MCP server or a conventional API.

On our side Balt consumes MCP servers rather than exposing their tools to the model, for a cost reason we own: every visible tool is paid for on every conversational turn, in every conversation, at every customer. So the model sees exactly one, and it writes code to call everything else. That is not the subject here, but it is why we look first at what a server lets you do and never at how many tools it advertises.

That leaves what happens when everything is connected and nothing changes, which is the most common case: the protocol was the easy problem, and what stops a project from landing is almost always somewhere else.