Hiring a new person starts long before the first candidate appears. It starts with a question: what should we actually offer? And with that question comes hours of manual searching — switching between job portals, digging up old offer letters, calling a friend at another company. The data exists. It's just never in one place.
The work nobody wants to do
An HR manager at a thirty-person company hires three or four times a year. Before each hire, they browse Jobs.cz, check Platy.cz, scan a few LinkedIn profiles with visible salaries, and pull out the spreadsheet where they've been logging offer amounts for the past two years. The result is a number that comes from roughly three hours of work and still carries a lot of uncertainty.
The problem isn't a lack of data. The problem is that the data lives in too many places — and nobody has yet built a bridge that connects it to a specific question from a specific person.
I have data on what we paid two years ago. I have a Jobs.cz snapshot from last week. And I have intuition from four hours of searching. I'm never sure the number is right.
— HR manager, manufacturing company, 45 employees — illustrative experience from practice
What "connected data" actually means
AI stack builds a small MCP server — one focused bridge — between Claude and the data sources the HR manager already has access to. The key word: already has access to. The MCP server doesn't carry an admin credential. It carries the logged-in user's identity. Claude never sees more than the person asking would see if they looked through those sources manually.
In practice, it works like this: the HR manager logs into the company's Claude instance on the company's own cloud. They type a question — something like "what's the current market range for a sales manager role in Brno?" Claude calls the MCP server. The MCP server checks the internal records (Excel, HRIS, Google Sheets — whatever the company uses) and simultaneously pulls current data from the public sources the company has access to. The result comes back structured: lower quartile, median, upper quartile, regional context, a note on comparable roles.
Concretely: what this looks like for a company with data in Excel and Jobs.cz
You don't migrate your data. Excel stays where it is. Jobs.cz stays Jobs.cz. One MCP server is added that knows how to look at those places using your identity. A three-person HR team doing four hires a year saves illustratively six to ten hours of prep annually — but more importantly, they stop second-guessing the number they quote to candidates.
- The HR manager types a plain-language query — role, location, optionally seniority or sector.
- Claude calls the MCP server, which searches internal records under the HR manager's permissions.
- Simultaneously, it pulls current data from public sources the company already has access to (job portals, or paid data sets).
- The result arrives as a structured overview with ranges, median, and context — ready to paste into an offer letter or a presentation for leadership.
- The entire interaction is logged in an audit trail on the company's own infrastructure.
An illustrative example: an HR manager at a fifteen-person IT firm in Brno used to spend around two hours assembling a salary overview before each hire. After connecting an MCP server to the internal salary spreadsheet and two portals the company already subscribes to, the same overview now takes about as long as it takes to set up the meeting room.
What a salary benchmark through Claude will not do — and why that's a good thing
Claude won't decide what to offer a specific candidate. It won't assess whether a candidate is worth the upper quartile. It knows nothing about your company culture, how urgently you need to fill the role this month, or what the budget can actually stretch to. Those things stay entirely with the HR manager and leadership.
And that's exactly why it works. A benchmark is information, not a decision. Claude is good at that part. A decision is a qualified judgement from someone who knows the full context. That's what an experienced HR manager is good at. Each does its own job.
What it would take
This isn't a year-long project. An MCP server for HR benchmarking is one focused bridge to data the company already has. It runs on company infrastructure — not our servers, not a shared cloud. One tenant, one audit log, no data shared with other customers.
What's left
The model is not the bottleneck. Claude knows how to assemble a structured salary overview — it does that well. The bottleneck is the gap between Claude and the data your company already has: salary records, historical offers, portal subscriptions. That gap is what we close.
If your HR managers are spending hours before each hire assembling an overview that could exist in minutes — write to us. A short call is enough for us to understand where the data lives and what the bridge needs to handle. The rest is building, not deliberating.