A large language model arriving in your lab is a brilliant new postdoc on their first morning: enormously well read, and completely unacquainted with the building. It knows chemistry. It does not know that your compound library moved to the new freezer in April, or which plates are queued for the Echo tomorrow morning. Until it can see your systems, it cannot help you with your work.
Model Context Protocol, or MCP, is how we close that gap. The shortest useful definition I have found is this: MCP is APIs for AI. If you understand why your systems have APIs, you already understand most of why they now need MCP servers too.
Start with the API
An API, an application programming interface, is the front door a software system offers to other software. Your LIMS has one. Your ELN has one. It defines what can be asked, in what format, and what comes back. APIs are the reason your instrument data reaches your inventory system without anyone retyping it.
APIs are also written for programmers. They assume a developer will read the documentation, work out which of the two hundred available calls is the right one, write code that formats the request correctly, and handle the response. That assumption is fine when a human is doing the integrating. It falls apart when the thing on the other end is a language model that needs to work out, in the moment, which system to ask and what to ask it.
This is the gap MCP fills. It takes the same underlying capability an API exposes and presents it in a form an AI model can discover and use on its own: a self-describing menu of what this system can do, written to be read by a model rather than by a developer. The model connects, asks the server what it offers, and gets back a structured list of tools with plain descriptions of each. "Find samples by compound ID." "Return the storage location of a plate." "Create an order."
That single design decision is what changes the economics. With a conventional API, someone must build an integration for every pairing of AI tool and system. Five AI assistants across eight systems is forty integrations to build and keep alive. With MCP, you build one server per system, and every MCP-capable AI can use it, including ones that do not exist yet. Forty becomes eight.
Where MCP came from
MCP is not a Cenevo invention and it is not a marketing term, which matters when you are deciding whether to build on it.
Anthropic, the AI research company behind the Claude models, designed the protocol and open-sourced it on 25 November 2024. The problem they set out to solve was exactly the one described above: models isolated behind information silos, with every new data source requiring its own bespoke implementation.
Within a year MCP had become one of the fastest-adopted open-source projects in AI, with around 97 million monthly SDK downloads and roughly 10,000 active servers. Client support now includes ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor and Visual Studio Code, which is to say every major AI platform, not one vendor's ecosystem.
In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a new body under the Linux Foundation, co-founded with Block and OpenAI and backed at platinum level by Amazon, Google and Microsoft. The protocol is now under neutral, multi-vendor governance in the same way Linux, Kubernetes and Node.js are.
For anyone in life sciences weighing up a long-lived investment, that governance point is not a detail. It means MCP is unlikely to be withdrawn, paywalled or bent to favour a single supplier, and it is the reason we were comfortable building on it rather than around it.
Why this is the bottleneck, not the model
Our 2026 Lab Operations Report, based on responses from more than 110 life sciences professionals, puts numbers to something most lab teams already feel. 55% cite lack of integration between systems as their biggest barrier to making effective use of lab data. 47% report data fragmented across instruments. Meanwhile 60% are exploring or piloting generative AI, but only 5% have agentic AI running in full production.
That gap between 60% and 5% is not a model problem. Models have improved faster than almost anyone predicted. It is an access problem. An agent that can reason brilliantly but cannot see your inventory, cannot read your protocols and cannot place an order is a very expensive chatbot.
So the constraint on AI value in the lab is no longer intelligence. It is context, and MCP is the mechanism for delivering that context reliably.
What it looks like in practice
Consider a scientist who asks, in plain language, "Which of our kinase inhibitors have enough material left for a full dose-response, and where are they stored?"
Answering that means reaching into a sample management system for quantities and locations, checking a registration system for compound identity, and possibly checking an ELN for what was used in the last screen. Today that is three logins, two exports and a spreadsheet.
With MCP servers in place, the agent connects to each system, reads the menu of available tools, selects the ones it needs, calls them, and assembles the answer in seconds. Nobody wrote a "kinase inhibitor availability" integration in advance. The capability was already exposed; the model worked out how to combine it.
Crucially, it does this as the scientist, not around them. If they cannot see a project's samples, neither can the agent acting on their behalf.
The part that matters most in regulated environments
Giving an AI agent access to your systems sounds, on the face of it, like a security problem. Done badly it is one. Done properly it is the opposite, because a standardised access layer is far easier to govern than a scatter of bespoke integrations and manual exports that nobody has fully mapped.
Three things make the difference:
- Permissions are inherited, not granted separately. The agent operates inside your existing security and permissions framework. There is no parallel set of AI credentials with their own access rules to maintain and audit.
- Actions run through the platform, not around it. Because agents act through Mosaic and Labguru rather than reaching into a database directly, every read and every change is captured by the platform's own audit trail. You are not bolting on AI logging after the fact.
- The boundary is explicit. An MCP server exposes a defined set of tools and nothing else. It is a controlled surface that you choose, not open access.
For labs working to GxP or ISO standards, that last point is what turns AI from an interesting pilot into something that can plausibly reach production. The agentic lab has to be a trusted lab, and trust here is a design decision made early rather than a control added late.
Why we are betting on an open standard
We could have built proprietary connectors. It would have been faster in the short term and it would have locked customers in, which some would regard as an advantage.
We chose not to, for a reason that I think holds up. Your lab does not only run Cenevo software. It runs quality management systems, manufacturing execution systems, CRMs, data lakes and a long tail of instruments and internal tools. An AI strategy that only works inside one vendor's boundary is not an AI strategy, it is a feature.
Because MCP is an open standard under neutral governance, every new server built anywhere makes your lab's connectivity slightly better, whether we built it or not. Our Labguru and Mosaic MCP servers expose experiments, protocols, inventory, samples, storage, orders and workflows through that same standard interface. They work with our agents. They also work with yours.
Where to start
If you are working out where MCP fits in your own plans, my advice is to resist starting with the agent. Start with the question you most want answered and trace it backwards. Which systems hold the pieces? Do those systems have APIs today, and can they be reached in a governed way, or does the answer currently depend on someone exporting a file?
That exercise tends to make the priorities obvious fairly quickly, and it produces something more useful than an AI roadmap: a list of the specific connections that would unlock real work.
APIs let your software talk to your software. MCP lets AI talk to all of it. It will not be the thing that impresses anyone in a demo, but it is the thing that determines whether the demo becomes a workflow.
To see how MCP connects AI agents to the systems your lab already runs on, book a demo or read more about our MCP servers.
%20(4).png)
