Most enterprise software forces you to work inside it. You open the platform, navigate to the thing you need, do the thing, close the tab. If you need to cross-reference something from another system, you open another tab. This is how it has worked for twenty years and it works fine – until you have six platforms and the context-switching starts costing more than the work itself.
The Model Context Protocol changes something about this. Not dramatically, not yet, but the direction is clear enough to be worth paying attention to.
GFoundry recently shipped an MCP server for their HR and talent platform. The short version: you can now manage GFoundry – query employee data, trigger actions, generate reports, surface insights – directly from Microsoft Copilot, ChatGPT, or Claude, without opening the backoffice. That is the headline. The more interesting part is what comes after it.
What MCP Actually Does Here
MCP is a protocol for connecting LLMs to external tools and data sources in a standardised way. You define a server that exposes capabilities – tools the model can call, resources it can read – and the LLM can invoke those capabilities as part of a conversation. The server handles authentication, permissions, and execution. The model handles language.
GFoundry’s implementation exposes what their backoffice users already do: reading people data, checking learning progress, understanding engagement signals, generating training content, pulling talent analytics. The difference is that you do it through a conversation in whatever LLM you are already using, rather than through the platform UI.
This is useful on its own. But it becomes considerably more useful when you think about what else is connected via MCP.
The Compounding Effect
Copilot, ChatGPT, and Claude all support multiple MCP servers simultaneously. Which means your conversation can span GFoundry, your payroll system, your CRM, your BI platform – if those systems also expose MCP servers – in a single thread.
The practical implication: a question like “which teams have the highest attrition risk and what does their compensation look like relative to market benchmarks” is currently a multi-system exercise. You pull people data from one place, comp data from another, external benchmarks from somewhere else, and you synthesise manually. With MCP-connected systems, that synthesis happens in the conversation.
This is probably where the real value is – not in replacing any single platform’s UI, but in collapsing the integration layer that currently lives in spreadsheets and human memory.
Gi Admin and the MCP – Same Question, Different Context
GFoundry already has a conversational analytics interface built into the backoffice: Gi Admin’s Data Analyst agent. You ask a question in natural language – “what is the engagement trend in the engineering team”, “which employees are flagged as at risk this quarter” – and you get an answer in seconds, with the option to export to Excel. Personal data does not reach the model. The access controls are the same ones the authenticated user already has.
The MCP does something similar. So it is reasonable to ask whether these two things are competing.
They overlap in one specific scenario: an HR analyst who is already inside GFoundry’s backoffice and also has Claude or Copilot open in another tab. In that situation, both interfaces answer the same type of question about the same data. The overlap is real.
But the contexts are different enough that this is probably not a problem worth solving. Gi Admin is the right tool when you are inside the platform – zero friction, no setup, purpose-built for the task. The MCP is the right tool when you are working across systems and GFoundry is one of several data sources in a broader question. The person using the MCP to ask about attrition risk is probably also pulling from payroll data and their CRM in the same conversation. Gi Admin does not do that.
The more interesting question is whether, over time, the MCP interface improves fast enough that it becomes the preferred entry point even for GFoundry-only queries. That would depend on how much of the Gi Admin capability gets exposed through the MCP server, and how good the ambient LLM context becomes at handling the specificity that HR analytics requires. For now, they serve different moments in the workflow. Whether that stays true is worth watching.
How GFoundry Thinks About This Architecturally
GFoundry’s framing for this sits inside what they call TOAR – Talent Orchestration, Automation and Response. The idea is a single orchestration layer over the systems an organisation already has, so data stops living in silos and starts being read together. The MCP integration is a natural extension of that thinking – if the goal is to make HR data actionable across contexts, then the LLM context is exactly where a lot of decision-making already happens.
Their Gi intelligence layer sits underneath this: specialised agents for learning design, role-play coaching, data analysis, and talent strategy, all trained on client-specific data while keeping PII server-side and out of the model’s direct reach.
On the Permission Model
This part matters and is easy to underestimate. The permissions the LLM operates under are inherited from the authenticated user. If you cannot see a particular employee’s data in the backoffice, the MCP server will not surface it to the model. The LLM is not a privilege escalation path – it is a different interface to the same access controls.
This is the right architecture. The alternative – where the model has broader access and filters outputs – is considerably harder to reason about and audit. Keeping the access boundary at the server level and logging all requests is how you make this auditable, which matters when HR data is involved.
What This Probably Looks Like in Practice
The honest answer is that we do not yet have strong evidence for exactly how enterprise users will work with LLM-connected HR systems at scale. The protocol is new, the integrations are new, and the workflows people will build around this are still being discovered.
What seems likely: the immediate use cases are query-heavy. “How many people completed the compliance training this quarter.” “What is the engagement trend for the engineering team.” “Summarise the capability gaps flagged in the last performance cycle.” These are things that currently require navigating a UI to get a number, and that are more naturally expressed as questions.
The more complex use cases – triggering actions, generating content, making decisions across multiple systems – will probably develop more slowly, as organisations build confidence in how the models handle the context and where human review still needs to happen.
The Broader Point
MCP as a protocol is still early. The tooling is maturing, the patterns for building reliable multi-system integrations are still being worked out, and the failure modes are not all documented yet.
But the direction is probably correct. The LLM is increasingly where knowledge workers spend time and make decisions. Having the systems those decisions depend on accessible in that context – with proper permission controls and audit trails – is a reasonable thing to build toward.
GFoundry shipping this for their HR platform is one data point in a pattern that will probably look obvious in a few years. For now it is worth watching how the usage patterns develop.
Pedro Trindade is Principal Engineer at Ubbin Labs.