How Climb Partnered with Databricks to Build the Biomedical MCP Layer for Healthcare & Life Sciences in 30 Days

At a Glance

Industry: Healthcare & Life Sciences

Goal: Build a suite of production-ready MCP servers for the most important open biomedical data sources, helping HLS teams connect AI agents to public data like FDA reports, clinical trials, and biomedical literature without weeks of integration work.

Tech Stack

• MCP servers and tooling: FastMCP (2.x), Python, uv workspace
• Hosting and deployment: containerized AWS Lambda, API Gateway, AWS CDK
• Governance and distribution: Databricks Marketplace, Unity Catalog

Outcomes

• 10 production-ready MCP servers delivered in 30 days, a scope most teams would plan as a quarter-long project.
• 49 purpose-built tools across ten open biomedical data sources, available to AI agents as native tools rather than standalone APIs.
• Zero custom integration work for customers: each server installs through the Databricks Marketplace with a Unity Catalog secured connection.
• A published foundation for expanding MCP-based access to additional healthcare, life sciences, and real-world evidence datasets.

The Problem: AI Agents Can't Easily Reach Public Biomedical Data

Healthcare and life sciences organizations building AI applications often face a data access problem rather than a compute or model problem. Critical datasets, including clinical trial registries, biomedical literature, and drug compound repositories, are publicly available, but integrating them requires custom API wrappers, schema translation, authentication management, data ingestion, and ongoing maintenance.

The Model Context Protocol (MCP) addresses this challenge by exposing data sources as standardized tools that AI agents can call directly. In practical terms, an MCP server gives an AI agent a consistent way to query a data source without the custom integration code each source would otherwise require.

Based on the demand in the HLS industry, Databricks recognized that many customers needed more than infrastructure. They were ready to build AI agents but kept stalling on the same bottleneck: the weeks of integration work required before an agent could reach the data it needed.

When the Databricks Healthcare & Life Sciences team approached Climb, the objective was clear: build a suite of MCPs for the most important open global biomedical data sources. Thirty days later, Climb delivered 10 MCP services spanning 10 open biomedical data sources and exposing 49 production-ready tools , all published to the Databricks Marketplace.

HLS companies can now integrate these MCP services directly into their Databricks workspace, putting their own private data and the public evidence base in one place. Researchers and analysts no longer lose hours to search, evidence collection, and stitching sources together; they can focus on the research itself and decide on the right action faster.

What Stood Between Open Datasets and Production AI Use

In partnership with the Databricks Healthcare & Life Sciences organization, Climb set out to build and publish MCP servers for ten open biomedical data sources most relevant to enterprise HLS workloads. The resulting portfolio spans the breadth of the life sciences ecosystem:

Three realities defined the difficulty of that ask.

Ten sources, ten sets of conventions. Each source introduced unique API conventions, schemas, authentication methods, and rate limits. There was no shared standard to build against; every server required its own integration approach before any of them could present a consistent surface to an AI agent.

Generic wrappers would not be enough. The servers had to serve the specific HLS use cases Databricks customers would bring to them, including drug discovery, medical science liaison workflows, and regulated reporting. Each service's MCP responses needed to map to those workflows, not simply pass API output through.

Often a single tool was not enough; a source needed several purpose-built tools, each exposing a different way to query the data, so the agent could find the right path to the answer a given question required.

Consistency, security, and speed at once. The challenge was not simply building ten servers but building them consistently, securely, and quickly enough to create immediate value for Databricks customers. The timeline was anchored to the Data + AI Summit, so the 30-day window left no room for rework or architectural dead ends.

How Climb Designed the MCP Servers

Climb Founding Solutions Architect Itai Weiss and Principal Architect Jim Rosser led the technical implementation, delivering all ten servers in 30 days. 

Several factors enabled that accelerated pace. The project scope was clearly defined from the outset: Databricks identified the target data sources, target audience, and Marketplace destination, eliminating lengthy discovery and prioritization cycles. Climb's senior engineering expertise, experience with the MCP specification, Databricks Marketplace publishing process, and healthcare and life sciences data ecosystem allowed the team to focus on execution rather than learning. 

And close collaboration between Climb and Databricks enabled rapid feedback, streamlined reviews, and efficient navigation of Marketplace requirements, helping maintain momentum throughout the project.

"HLS teams have been asking for agent-ready access to open biomedical data for some time. Climb built in a month what most teams would scope as a quarter-long project. The speed and quality set a new bar for partner builds."

Jay Bhankharia, Head of Industry Product Partnerships, Databricks

One Server per Data Source

Rather than creating a single federated gateway, the team built each MCP server as an independent service with its own tool surface, operational boundaries, caching strategy, and lifecycle. This approach improves reliability, simplifies maintenance, and allows customers to deploy only the MCP servers relevant to their specific workflows.

The Exception: One Server That Combines Many Sources

The BioContextAI Knowledgebase server was the sole exception to the single-source pattern. It federates curated capabilities from AlphaFold, STRING, UniProt, Reactome, Human Protein Atlas, InterPro, PanglaoDB, PRIDE, and Europe PMC, providing complementary structural biology and proteomics intelligence not covered by the other MCP servers.

Tools Written Once, Able to Run Anywhere

Every server is built on FastMCP (2.x) in Python. The core design decision was to decouple the tools from the framework: each data source's tools are written as pure-Python functions, and thin adapters wire those functions into whichever runtime is needed. The same tool code runs unchanged both as a self-hosted HTTP server and as an AWS Lambda handler, which means every tool can be validated locally before it ever reaches cloud infrastructure.

Shared Code, Independent Deployment

The repo is a uv workspace where each server is an independent member with its own dependencies, container image, and infrastructure definition, sharing a common runtime library (auth, metrics, HTTP client) and a common set of CDK constructs. 

The servers run as containerized AWS Lambda functions, each fronted by its own API Gateway endpoint, delivered as a managed endpoint through the Databricks Marketplace. Every data source is an independent CDK stack with its own Lambda, gateway, authorizer, log group, and keep-warm schedule, so servers are deployed and rolled back in isolation. Deployments run through a standardized task runner exposed to engineers, CI, and IDE assistants alike, and toolchain versions are pinned for reproducible builds. The identical code also runs as a local HTTP server for development.

Designed Around Real HLS Workflows

Working closely with Databricks throughout the build, we tuned each service so its MCP responses mapped to the specific HLS use cases they would serve, including drug discovery, medical science liaison workflows, regulated reporting, and many others. For every source, that meant working through the available API options, unpacking how it structured its requests and responses, and shaping the resulting tools around the questions HLS teams actually ask. 

Close collaboration between Climb and Databricks enabled rapid feedback, streamlined reviews, and efficient navigation of Marketplace requirements, helping maintain momentum throughout the project.

Secure, Governed Access Through the Databricks Marketplace

Installation is done through the Databricks Marketplace, which creates a Unity Catalog secured connection and exposes each service's MCP tools within the Databricks ecosystem. Governance lives where the customer's data governance already lives, and no separate access layer is required.

The Result: Public Biomedical Data, Ready for AI Agents

What the MCP Servers Can Do

Thirty days later, Climb delivered 10 MCP services spanning 10 open biomedical data sources and exposing 49 production-ready tools, all published to the Databricks Marketplace.

49 purpose-built tools across 10 servers. Across the 10 servers, customers gain access to 49 purpose-built tools designed to accelerate AI-driven research and analytics workflows. Each tool was tuned against the HLS use case it serves rather than shipped as a raw API passthrough.

The public corpus, within reach of a single agent call. The services put 2.4M+ bioactive compounds (ChEMBL), 35M+ biomedical citations (PubMed), 500,000+ global clinical trials (ClinicalTrials.gov), 20M+ FAERS adverse event reports (OpenFDA), 1,000+ biomedical ontologies including SNOMED CT, ICD-10, LOINC, and RxNorm (BioPortal), and scored associations across 60,000+ gene targets and 20,000+ diseases (Open Targets) directly in front of Databricks agents.

Independent, isolated services. Each server carries its own tool surface, operational boundaries, caching strategy, and lifecycle, so a change or failure in one service never affects another, and customers deploy only what their workflows need.

Governed, observable, and fully hosted. Every Marketplace installation creates a Unity Catalog secured connection, so access is managed within the customer's existing Databricks governance perimeter. The services ship with hardened authentication and MLflow traces, and the suite stays hosted and maintained, so there is nothing for customers to operate.

What Medical Teams Get Out of It

Whether identifying FDA adverse event signals, retrieving clinical trial eligibility criteria, mapping genes to disease associations, or analyzing population health trends, teams can access these datasets as native AI tools rather than standalone APIs. In practice, that unlocks workflows across every part of the HLS organization.

Immediate availability, no integration backlog. The ten MCP servers are now available through the Databricks Marketplace as part of the Climb Labs MCP Services for Healthcare & Life Sciences. Databricks customers can immediately connect AI agents to leading biomedical data sources without building and maintaining custom integrations, with agents reasoning over public evidence alongside the organization's own data.

Discovery and translational R&D. Teams can evaluate candidate molecules and their liabilities, connect targets to diseases with supporting evidence, stay current with peer-reviewed and preprint literature, and ground answers in structured biology across genes, proteins, and pathways.

Clinical development. Teams can automate trial feasibility analysis, benchmark protocol design, evaluate patient eligibility, and monitor competitor pipeline activity, while pharmacovigilance and regulatory teams detect safety signals, review label content, and track recall activity.

Commercial, market access, and population health. Teams can verify payer coverage criteria and monitor policy changes, standardize clinical terminology across systems and data partners, and build social determinants of health risk profiles for site selection, health equity reporting, and market sizing.

Research cycles in weeks instead of quarters. For healthcare and life sciences organizations building AI on Databricks, that shift removes significant engineering overhead and accelerates the path from proof of concept to production. Instead of spending quarters wiring up public data sources one at a time, research teams can inform decisions with the full evidence base and deliver outcomes within the current planning cycle.

A foundation, not an endpoint. This release establishes a foundation for expanding MCP-based access to additional healthcare, life sciences, and real-world evidence datasets across the Databricks ecosystem.