cancel
Showing results for 
Search instead for 
Did you mean: 
Technical Blog
Explore in-depth articles, tutorials, and insights on data analytics and machine learning in the Databricks Technical Blog. Stay updated on industry trends, best practices, and advanced techniques.
cancel
Showing results for 
Search instead for 
Did you mean: 
jiayi-wu
Databricks Employee
Databricks Employee

If you’ve been curious about MCP—the latest buzzword in the AI tooling space—you might already know it was developed by Anthropic and open-sourced in late 2024. Maybe you’ve seen it described as “the USB-C for AI agents”, or you have built some agent applications, but still wondered how MCP would change the story? In this blog, we’ll peel back the layers of MCP and get to the core of what it actually offers—especially what it means to you, our Databricks’ AI customers.

What is MCP?

Model Context Protocol (MCP) defines a protocol to provide context to a Large Language Model. It is an open standard that helps AI agents interact with tools—like databases, APIs, or systems—in a consistent and reliable way. 

Let’s start with the general architecture of MCP as below. We will walk through a Databricks’ version in later sections.

general_mcp.png

General MCP Architecture

On the right side, you’ll see data assets—these could come from a database or a SaaS application. They are accessed via tools, which are connected to an MCP server. The MCP server acts as a compute layer that executes the logic you've defined.

On the left side of the diagram, you have the MCP client—typically an agent—sending requests to the MCP server. For example, the agent might ask, “Hi MCP server, can you fetch similar transactions using vector search indexes for me?” The server responds with the results. They communicate through structured requests and responses. The MCP protocol ensures both the request and response are interpreted and formatted in a consistent, standardized way.

Why do we need MCP?

There are two key reasons why MCP is needed.

First, it addresses a common problem: tool usage was messy and inconsistent. This challenge affects both LLM developers and application engineers. Anthropic encountered this friction internally and created a standardized middle layer to resolve it—what eventually became MCP.

Second, the industry is moving toward a future where more than half of all use cases—and token consumption—will come from agents repeatedly calling tools in a loop. Standardizing how tools are defined and invoked leads to greater consistency, which drives higher efficiency and, ultimately, greater business value.

Screenshot 2025-06-11 at 11.30.01 AM.png

Inconsistent agent calling tools (source)

For example, without MCP, different teams might call the same weather API but return results in completely different formats—one as a JSON object, another as a plain string, and yet another as a pandas DataFrame. This inconsistency puts a heavy burden on your LLM, which now has to handle varying formats and even different programming languages. Smaller models may struggle or return incoherent results, exposing a major pain point in tool standardization.

The challenge doesn’t stop there. On other platforms like LangGraph, there’s no easy way to list or describe all available tools without reading through the code or managing separate documentation. Governance adds another layer of complexity. In contrast, Databricks customers avoid these issues entirely—tools are natively integrated with Unity Catalog and consistently governed using Service Principals.

All of this shows how messy and inefficient tool management can become without a standard like MCP. It slows down development, increases errors, and delays time to production.

Why MCP on Databricks? 

While MCP offers an open, consistent protocol with strong community momentum, enterprise use cases often demand additional layers—such as robust governance, secure access, and operational efficiency in scale.

This is where Databricks shines. Databricks’ customers can leverage MCP to surface all kinds of tools to AI agents with reliable infrastructure support, enhancing its strengths with enterprise-ready capabilities. Hosting MCP servers (and clients) on Databricks brings:

  • Enterprise-grade governance with Unity Catalog, enabling fine-grained access control, audit logging, and service principal-based authentication to ensure tools are used securely and compliantly.
  • Seamless integration with enterprise data—whether it's structured data in Delta tables, unstructured documents, vector search indexes, or even telemetry from external systems—making it easy for agents to access the right context without leaving the platform.
  • Built-in observability through Mosaic AI Gateway, MLflow evaluation, and MLflow tracing, giving developers full visibility into tool usage, model behavior, and agent workflows for debugging, and evaluation.
  • Flexible and scalable infrastructure with lightweight serverless compute via Databricks Apps to run tool logic efficiently, allowing enterprises to scale agent and tools interactions without overprovisioning resources.

What use cases can Databricks customers unlock with MCP?

Integrating MCP into Databricks unlocks a wide range of enterprise-ready AI use cases:

  • Build and govern MCP servers on Databricks Apps using lightweight compute to wrap custom tools that access Delta tables, external APIs, or legacy systems—scaling your logic with minimal overhead.
  • Develop enterprise-grade agents connected to tools via MCP, exposing data from Unity Catalog, Genie space, or Vector Search indexes, with full observability through Mosaic AI Gateway and MLflow Tracing.
  • Host agents on Databricks that call external MCP servers, enabling seamless integration with systems like Salesforce or other off-platform services through a unified, secure interface.

Any examples of using MCP on Databricks?

Yes! The architectural example below shows how a Quality-Control AI Agent, deployed on Databricks, uses MCP to answer maintenance questions and take actions across systems.

mcp_databricks_example.png

MCP on Databricks with an Example Use Case

The interaction follows these steps:

  • Step 1: User Query: “Hey QC-Agent, what’s the status of Machine #1234? Any defects I should know about—and if so, please open a maintenance ticket.”
  • Step 2: Gather Documentation: The agent queries MCP Server #1: InfoHub to fetch relevant documents from Databricks-hosted data sources
  • Step 3: Fetch Metrics: The agent queries MCP Server #2: TelemetryServer to retrieve real-time machine data from an external MySQL database
  • Step 4: Analyze & Confirm Anomaly: The agent processes the documents and sensor metrics with an LLM. It detects vibration readings 3σ above normal and flags a likely defect.
  • Step 5: Notify & Open Ticket: To initiate follow-up, the agent contacts MCP Server #3: SlackMCP, hosted on Databricks to send an alert and file a JIRA ticket.
  • Step 6: Respond to the User: “I found elevated vibration levels on Machine #1234 and opened a high-priority ticket in JIRA. I’ve also posted an alert in #maintenance-alerts. Let me know if you'd like more details!”

What does the Architecture of MCP on Databricks look like?

You might wonder—if I want to use MCP on Databricks, which components run on Databricks, and which don’t? How flexible is the architecture? In the example below, we showcase an AI agent (the MCP client) deployed on Databricks that interacts with three MCP servers. The plot below uses the same example and illustrates how each component works and how the architecture can be extended for other use cases.

mcp_databricks_governance.png

MCP on Databricks with Governance, Scalability and Extensibility

On the left, the MCP client is an agent deployed on Databricks. It could also be an agent running elsewhere that calls an MCP server hosted on Databricks via the streamableHTTP MCP protocol. If you're using a local MCP client (such as from an IDE), the stdio+SSE protocol is used instead.

In the middle, all three MCP Servers are hosted on Databricks using Databricks Apps. These are lightweight compute environments that support long-running processes and integrate seamlessly with existing workflows. This makes them ideal for hosting custom MCP logic with consistent governance. Tools are registered to these servers using functions like @mcp.tool() or @app.call_tools(). This is similar to @tool when using the LangGraph framework.

On the right, tools query data assets—these can reside in Databricks (such as Delta tables or vector indexes), in external databases like MySQL, or in SaaS platforms like Slack. This decoupled design allows you to mix and match your infrastructure and tools while keeping the agent logic centralized and governed.

What business value does MCP unlock when built on Databricks?

By running MCP on Databricks, organizations can unlock strategic value across governance, scalability, and extensibility—making it easier to build secure, efficient, and future-ready AI systems:

  • Increase the reach and impact of internal tools by exposing MCP servers to downstream teams and external partners. This promotes collaboration while maintaining centralized governance and control.
  • Accelerate internal development by standardizing how agents interact with tools, minimize custom development of scripts, enabling teams to build solutions quickly with consistency.
  • Extend the life of legacy systems by making them accessible through MCP, so they can continue delivering value without requiring immediate modernization.

With Databricks, the power of MCP becomes enterprise-ready. Unity Catalog ensures secure and governed access, while flexible infrastructure enables seamless scaling of tool logic. Native integration with AI and ML tooling—like MLflow and Mosaic AI Gateway—further simplifies observability and lifecycle management. Whether you're building agents, wrapping legacy systems, or exposing tools across teams, Databricks provides the control, scalability, and openness to make MCP practical in real-world production environments. Check out Databricks MCP API doc and more code instructions here!