Your Hiring Data Should Be Reachable From Any AI. That's What MCP Is For.
The questions people ask about a hiring pipeline are different every time, which is exactly what a dashboard can't handle. The Model Context Protocol changes the shape of the problem.
Every SaaS tool you use has a dashboard. Each one is a place you have to go, with its own navigation, its own filters, and its own idea of which question you were going to ask.
The questions people actually have about a hiring pipeline rarely fit that shape. Which of my searches has the worst reply rate and why. Everyone who responded positively this week, in a table, with their current company. A summary of where each open role stands, for tomorrow's leadership meeting.
Those aren't dashboard views. They're questions, and they're different every time. Building a view for each one isn't possible, which is why every tool eventually accretes a CSV export and a reporting tab nobody likes.
What MCP Actually Is
The Model Context Protocol is an open standard, originally published by Anthropic and now adopted broadly, that defines how an AI assistant connects to an external system — how a server describes the tools it offers, how the assistant calls them, and how results come back.
Before MCP, connecting an assistant to a system meant a bespoke integration per assistant per tool. An N×M problem that guaranteed most combinations would never get built. MCP collapses it: implement one server, and any compatible client can use it.
The practical consequence is that the interface to your data stops being a screen and becomes a conversation, inside whichever assistant you already work in.
Why Recruiting Fits Unusually Well
Three properties make recruiting data a good candidate for this.
The questions are open-ended and non-repeating. Unlike accounting, where queries are largely standardised, every hiring conversation generates a slightly different one. That's exactly the case where a fixed interface underperforms.
The data is relational in ways that suit language models. Candidates, searches, criteria, messages, scores, notes. Answering something real — which criteria are shortlisted candidates failing most often — requires reasoning over structure rather than looking up a value.
Recruiting work spans tools. The candidate lives in a sourcing platform, the conversation in LinkedIn, the interview in a calendar, the debrief in Notion or Slack. An assistant with access to several MCP servers can move between them in a single request, which no individual product can do. "Take everyone I've exchanged messages with this week and add them to this Notion page with their scores" is otherwise twenty minutes of copy-paste.
What We Learned Building One
Some of this isn't obvious from the specification.
Tools should be shaped like questions, not database tables. The early instinct is to expose CRUD operations per entity and let the model compose them. It works badly — the model burns turns assembling joins and often gets the semantics wrong. Tools that map to what people actually want, like "candidates awaiting a decision," produce far better results.
Descriptions are the real interface. The model chooses tools based on how they're described. A precise account of what a tool returns, what its parameters mean, and critically whether it's read-only or destructive, is the difference between a server that works and one that misfires. This is prompt engineering wearing an API's clothes.
Reads and writes need different treatment. Reads can be freely available. Anything that sends a message, archives a candidate or changes pipeline state should be marked destructive and require confirmation. An assistant that can silently contact forty people isn't a feature — it's the governance failure with a new interface.
Return context, not just values. A tool that returns a score returns a number the model can't reason about. Returning the score plus the per-criterion breakdown lets it explain, compare and justify. Slightly more tokens, dramatically more useful.
The Discovery Shift Nobody Mentions
There's a second-order effect worth naming. As more work moves into assistants, the way software gets found changes. People increasingly ask an AI which tool solves a problem rather than searching for it.
A product reachable via MCP is one an assistant can recommend and then immediately use. That's a meaningfully different position from being a URL in a list of results. It's early, and the mechanics are still forming, but the direction looks clear.
We're at VivaTech this week, booth 2B10-002, and this is most of what we expect to end up talking about.
The Umamy MCP server connects your hunts, candidates, scores and conversations to Claude, ChatGPT and any other MCP-compatible assistant — reads open, writes behind confirmation.