Why MCP is the API layer enterprise HR has been waiting for

1. The integration problem nobody quite solved

Enterprise HR runs on integrations. The HRMS talks to the finance ERP, the identity provider, the payroll service, the tax engine, the background-check vendor, the LMS, the performance tool, the time-tracking app, the wellbeing app, the recognition app. None of these systems were designed to talk to each other directly. So every customer pays an integration team to build the bridges, and every vendor publishes an SDK and a docs site and hopes the customer team chooses well.

This worked for twenty years. REST and GraphQL APIs got us a workable web of services. Integration vendors got us Zapier and Mulesoft and Workato. Customers built middleware. The cost was high but predictable.

Then AI assistants happened. And the integration model broke. Suddenly the question was not “which two systems need to talk?” but “how does this assistant act on every system the user already runs?” The economics of bespoke-per-integration stopped working the moment one user expected one chat window to reach everything.

2. What MCP is, in plain language

The Model Context Protocol is a standard for how AI assistants discover and invoke tools on external systems. It does what HTTP did for documents and what GraphQL did for typed data: it standardises the contract between a consumer (the AI client) and a provider (the system that exposes capabilities).

Three things matter about it.

• Discovery is built-in. An MCP-compliant server tells the client which tools exist, what they do, and what arguments they take. The assistant does not need a hand-written integration manual. The tool descriptions are the manual.
• Invocation is uniform. Calling a tool looks the same whether the underlying implementation is REST, GraphQL, a database query, a shell command, or a remote procedure. The protocol abstracts the mechanism.
• Authentication is per-key. An MCP server can issue scoped credentials. The client carries a key that resolves to whatever subset of capabilities the server decides to allow.

The protocol itself is not the breakthrough. The breakthrough is what becomes possible once the contract is standard.

3. Why enterprise HR is the right fit

Several characteristics of enterprise HR make it unusually well-suited to an MCP-shaped integration layer.

HR data is multi-tenant by nature. Every customer of an HRMS is a separate company with separate data. The shape of access control is tenant-first: who you are AND which company you belong to determines what you can see. MCP's per-key scope model maps onto this cleanly. One key per tenant. One scope envelope per key. No cross-tenant leakage is even expressible.

HR data is sensitive. Salaries, bank accounts, tax IDs, performance reviews, personal addresses. Every read needs to be auditable. Every write needs to be challengeable. The traditional way to handle this is bespoke security middleware per integration. MCP lets us bake the safety model into the server: read-only flags, fail-closed defaults, OTP gating on sensitive operations. Every assistant inherits the safety model by virtue of speaking the protocol.

HR workflows cross many systems. A new-joiner workflow touches the HRMS, the identity provider, the payroll service, the laptop-provisioning tool, the badge system, the welcome-email service. Today that is glue code written by a customer. Tomorrow it is an AI assistant orchestrating the same systems through MCP servers each of them exposes. The orchestration burden moves from the customer to the protocol.

AI assistants are increasingly central to HR. Recruiters use AI to triage candidates. HR business partners use it to draft policy. Employees use it to ask about leave balances and reimbursements. The assistant-first surface is no longer an experiment. It is the way work gets done. MCP is how those assistants reach into the HR system without anyone writing a custom integration.

4. How we exposed HONO via MCP

HONO is a multi-tenant HRMS serving 300+ enterprise clients. The MCP surface had to respect that topology from day one, not retrofit it.

Two URL shapes for the server. Path-based: /api/:tenant/mcp. Subdomain-based: <tenant>.mcp.hono.ai/mcp. The subdomain form is the preferred one; it is cleaner to paste into an external client configuration, and it makes the tenant identifier visually obvious to the administrator setting it up. Slug rules are tight: exactly one level, case-insensitive, a regex that closes the obvious confused-deputy gaps, and a reserved-subdomain list that prevents anyone from registering admin or api as a tenant slug.

One key per tenant, scoped from creation. Each MCP API key is issued against a specific tenant and carries a read_only flag. The key is the thing the external assistant carries; the scope envelope is computed server-side at request time. A leaked key cannot escalate its own scope. A leaked key cannot reach a different tenant.

The flow looks like this end to end.

5. The safety model

Exposing an HRMS to a probabilistic system over a protocol designed for free-form invocation is not a thing to take lightly. The HONO MCP surface assumes the assistant will occasionally try things it should not. The server, not the client, enforces what is allowed.

Fail-closed by name prefix. Tool classification is deterministic and conservative. Tools whose names start with get_, list_, fetch_, search_, view_, or preview_ are classed as read. Everything else is classed as mutating. New tools added to the catalog default to protected; a reviewer has to explicitly opt them into the read scope. The default is the safe one.

Layered with the tenant module filter. Before scope classification, the server filters by what the tenant has paid for. A read-only external key sees the intersection of (tenant's enabled modules) ∩ (read-scope tools). A hospitality tenant's key cannot reach manufacturing tools because those modules are not in their enabled set, regardless of how the key is scoped.

Same execution invariants as the internal surface. Once a tool passes scope, it runs through the same Intelligent Execution Engine that the conversational Zero UI surface uses. The 45-second hard ceiling, the date validator on writes, the OTP gating on sensitive operations — all of it applies. Conversation may be the interface inside the HRMS; the protocol may be the interface outside it. The safety model is the same in both worlds.

The interface is not the product. Now the execution layer does not have to be ours either.

6. The Any-API discovery flow

The curated MCP tool set covers the high-value paths the average customer needs: leave balance, attendance, payslip, team list, recruitment status, performance actions. It does not cover everything. HONO's underlying surface is a catalog of around 1,429 GraphQL operations across modules and tenants. Curating every last one of them into the MCP tool list would be unbounded work.

So we built a discovery layer next to the curated tools: the Any-API flow. The assistant queries this layer with an intent description; the server searches the catalog; the response is an HMAC-signed, single-use, 5-minute-TTL endpoint envelope. The envelope is what the assistant uses to invoke the long-tail operation, with the signature ensuring it is the legitimate envelope the discovery layer returned, the single-use property ensuring it cannot be replayed, and the TTL ensuring it cannot be hoarded.

Phase 1 — discovery — is live. The assistant can find operations that exist outside the curated tool list and receive an envelope describing them. Phase 2 — actual invocation through the envelope — is the next layer of work. When it lands, the assistant has reach across the full operational surface of the platform without any vendor-team curation in the middle.

7. What this enables in practice

The point of the protocol is that the experiences become possible without anyone writing a custom integration. A few examples we already see today.

A manager opens Claude Desktop, types “show me my direct reports' leave plans for the next two weeks,” and the assistant calls the MCP server, fans out across the team, and renders the answer inline. The manager never opened HONO. The HR admin never wrote glue code.

A senior engineer in Cursor types “generate the recruitment-pipeline migration script for our new applicant tracking flow” and the assistant reads the current pipeline configuration through the MCP server, drafts the migration, and proposes it as a diff. The engineer reviews. The migration ships.

A workflow in Zapier wires a new-hire signed offer in the recruitment system to a series of MCP calls that provision the laptop request, register the badge, and schedule the welcome email. The customer's integration team wrote zero lines of code. The Zapier workflow author wrote the orchestration once.

The pattern in all three: the assistant the user already runs becomes the interface. HONO is reached through the protocol. No custom code.

8. What this means for HR-tech

Two parallel shifts are happening in HR software, and MCP is the load-bearing piece that connects them.

The first shift is the move toward headless. The Headless HRMS thesis — that the conversational layer replaces the screens, and the system becomes a vocabulary of intents rather than a tree of pages — is already in production. HONO Zero UI is the first implementation of it. Other vendors will follow.

The second shift is the move toward composable. The customer increasingly does not want a single all-in-one HRMS that owns the assistant experience. They want their assistant of choice to reach across whichever systems they already pay for.

MCP is what makes the two shifts coherent. Headless says the interface is not the product. MCP says the interface does not even have to be ours. Together they redraw the lines of where an HR vendor's product surface begins and ends.

Headless HRMS made the interface optional. MCP makes the vendor's interface optional too.

9. Where this is going

• Any-API Phase 2 — full invocation across the catalog. The HMAC-signed envelope is already there. Wiring it to invocation opens the long tail of operations the curated tool list does not cover.
• An MCP marketplace for HR. Today the HONO MCP server is one node. Tomorrow, every enterprise should expose its own MCP node for the systems unique to them — their proprietary HRIS, their custom payroll engine, their in-house badge system. A curated catalog of such servers turns the AI assistant into a true orchestrator across the organisation's real software estate.
• Multimodal invocation. Voice as input, on-screen context as input, document upload as input — same MCP server, different intent surface. The protocol is shape-agnostic. The HR assistant of 2027 is not typed; it is heard, watched, and spoken to.