# How Climb Partnered with Databricks to Build the Biomedical MCP Layer for Healthcare & Life Sciences in 30 Days | Climb Source: https://climb.ai/case-studies/climb-labs-mcp-service-for-hls-databricks Case study · Healthcare & life sciences # How Climb Partnered with Databricks to Build the Biomedical MCP Layer for Healthcare & Life Sciences in 30 Days July 8, 2026 At a Glance ## At a Glance Industry Healthcare & Life Sciences Goal Build a suite of production-ready MCP servers for the most important open biomedical data sources, in partnership with the Databricks Healthcare & Life Sciences team. ## 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 Story 1. [001 Overview](#s1) 2. [002 The Technical Challenge](#s2) 3. [003 Our Solution](#s3) 4. [004 Outcomes](#s4) Expand all Collapse all ## Overview AI Agents Can't Easily Reach Public Biomedical Data - · Databricks customers were ready to build agents, but every public dataset first needed custom API wrappers, schema translation and auth handling. - · We used MCP to expose each source as a standardized tool an agent can call directly, so that integration work never has to be repeated. - · Databricks scoped us to the ten open biomedical sources most relevant to enterprise HLS workloads. - · We delivered all ten in 30 days, with 49 production-ready tools published to the Databricks Marketplace. + Read the full section 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, 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 custom code written for each one. Databricks recognized that many HLS 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](https://climb.ai/labs/hls-mcp/), all published to the Databricks Marketplace. − Collapse to key points ## The Technical Challenge What Stood Between Open Datasets and Production AI Use - · Each source came with its own API conventions, schemas, auth methods and rate limits, so there was no shared standard to build against. - · A generic API passthrough would not have served drug discovery, MSL or regulated reporting workflows, so we mapped each tool's responses to the use case behind it. - · The launch was anchored to the Data + AI Summit, so the 30-day window left no room for rework or architectural dead ends. + Read the full section 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](https://climb.ai/labs/hls-mcp/) spans the breadth of the life sciences ecosystem: 01 Open Targets target, disease, and drug associations 02 BioPortal biomedical ontologies and terminology 03 ClinicalTrials.gov clinical trial registry 04 PubMed biomedical literature 05 ChEMBL bioactive compounds 06 U.S. Census ACS population health and social determinants of health 07 bioRxiv and medRxiv life sciences preprints 08 CMS Medicare Coverage Database coverage determinations 09 OpenFDA drug safety and regulatory data 10 BioContextAI Knowledgebase protein, pathway, and structural biology intelligence 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. **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. − Collapse to key points ## Our Solution How Climb Designed the MCP Servers - · We built one independent server per data source rather than a federated gateway, so each has its own tool surface, caching strategy and lifecycle. BioContextAI Knowledgebase was the exception: it federates nine structural biology and proteomics sources that are only useful in combination. - · We wrote the tools as pure-Python functions decoupled from FastMCP, with thin adapters for each runtime, so identical code runs as a local HTTP server and as a Lambda handler, so every tool was validated locally before it hit cloud infrastructure. - · We kept everything in one uv workspace over a shared runtime library and common CDK constructs, but gave each source its own stack, so services deploy and roll back in isolation. - · We published through the Databricks Marketplace, where installation creates a Unity Catalog secured connection, so governance stays in the customer's existing perimeter with no separate access layer. [Solutions architecture · scroll to pan Open interactive version →](/assets/insights-page/climb-labs-mcp-service-for-hls-databricks/solutions-architecture.html?v=354534afe6) + Read the full section 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. [Solutions architecture · scroll to pan Open interactive version →](/assets/insights-page/climb-labs-mcp-service-for-hls-databricks/solutions-architecture.html?v=354534afe6) ### 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. 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. − Collapse to key points ## Outcomes From Standalone APIs to Native AI Tools - · Customers can now point an agent at these datasets the same day, with no custom integrations to build or maintain. - · The 49 tools put the public evidence base one call away: 2.4M+ compounds, 35M+ citations, 500K+ trials, 20M+ FAERS reports, 1,000+ ontologies and scored target–disease associations. - · We ship the suite hosted and maintained, with hardened authentication and MLflow traces, so there is nothing for customers to operate. - · Research programs that used to spend quarters wiring up sources one at a time now move from proof of concept to production in weeks. + Read the full section ### 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. − Collapse to key points