Integrating Managed, External, and Custom MCP Servers on Databricks

1.Three places an agent's MCP tools can come from

Tools let an agent do more than generate text. With tools it can search documents, query tables, call external APIs or run code. On Databricks, the Model Context Protocol (MCP) is one way to connect those tools. MCP is an open-source standard, and every MCP server, whoever runs it, exposes tools through the same interface. On the exam, the question is rarely how to call an MCP tool, because the call looks the same everywhere. The question is which kind of server meets the requirement you are given.

Databricks gives you three options. Managed MCP servers are ready-to-use servers that Databricks hosts. They give agents governed access to your own Databricks assets: Genie, AI Search indexes, Databricks SQL and Unity Catalog functions. MCP Services are Unity Catalog securables. An MCP Service either provides a Databricks-hosted tool or registers an external MCP server. This is how you reach third-party SaaS such as Slack or GitHub, or a self-hosted server you want to govern. Custom MCP servers are your own code, or a third-party server you run yourself, deployed as a Databricks app. To see the servers available to you, go to your workspace and open AI Gateway > MCPs.

Sources123

2.Managed MCP servers: governed access to your Databricks data

Use a managed server when the agent needs data and logic that already live in Databricks. You have nothing to set up: Databricks hosts the servers and handles authentication. Unity Catalog enforces permissions, so an agent or user reaches only the tools and data you have granted to them. Each server has its own URL pattern. If your application uses on-behalf-of-user authentication, it also needs the OAuth scope for each server it calls.

Genie One is the odd one out in this table. The managed-server page lists it, but its URL uses the /ai-gateway/mcp-services/system.ai... form of an MCP Service, not the /api/2.0/mcp/ form, and its scope is ai-gateway. The system.ai schema also holds ready-made functions that agents call through the Unity Catalog functions server. One example is the code interpreter, system.ai.python_exec, which lets an agent run Python with no setup.

When choosing among these servers, match the server to the question being asked. For analytics, the docs recommend starting with Genie One. Genie resolves business terms through Genie Ontology, your governed semantic layer, and that gives more accurate answers than an agent writing SQL against raw tables. Use the Databricks SQL server when you already have a specific query to run, for example to validate its syntax or to author a pipeline.

Managed servers take parameters in two ways. Tool call arguments are usually generated by the LLM from user input. **_meta parameters** are configuration you preset in agent code when you want behavior to be deterministic. Cost follows the feature behind each server. Unity Catalog functions use serverless general compute pricing, Genie Agents use serverless SQL compute pricing, Databricks SQL servers use Databricks SQL pricing, and AI Search indexes use AI Search pricing.

Sources4

3.External MCP servers: governing them as MCP Services

Sometimes the tool lives outside Databricks: Slack, GitHub, Jira, Google Drive, or a server your team runs elsewhere. When the external service publishes an MCP server, the recommended approach is an MCP Service. An MCP Service is a Unity Catalog securable with a three-level name, catalog.schema.mcp_service, and you invoke it through Unity Gateway. Because it is a Unity Catalog securable, you manage it with the same tools you use for other Unity Catalog assets: grants control who can invoke it, tool selection limits which tools it exposes, service policies allow or deny individual tool calls, and audit logging tracks every call.

There are two ways to get an MCP Service. Databricks-provided services live in the system.ai schema and need no setup. You host no server and create no connection. Register your own when you have a self-hosted or third-party MCP server that you want to govern as a Unity Catalog securable.

You govern built-in services with grants, not with custom tool selection or policy functions. They come with platform-managed tools and a built-in service policy, which can, for example, block write operations. Some constraints can rule a service in or out for a given requirement:

- For Google Drive, Gmail, Google Calendar and Microsoft 365, each user completes a one-time OAuth login before their first call. - system.ai.web_search is not available in workspaces that have HIPAA/BAA compliance enabled. - system.ai.sandbox has no network egress.

To register your own server, go to AI Gateway > MCPs > Register MCP Server, or open a schema in Catalog and click Create > MCP Service. You attach a Unity Catalog HTTP connection to the server and choose which tools to expose. Through the REST API, an include_tool_selectors allowlist restricts the tools; leave it out to expose them all. You can also create services with the CLI, the SDKs, Terraform or Declarative Automation Bundles, but not with SQL DDL. For managed-OAuth providers that publish an MCP server, such as Glean, GitHub, Atlassian and Slack, Databricks can manage the OAuth credentials when you register the server as an MCP Service.

MCP Services are not the only way to reach external services. You can also use managed OAuth, call REST APIs directly, or write Unity Catalog function tools that wrap http_request(). Those options belong to other lessons. For this objective, the rule is: if the service publishes an MCP server, use an MCP Service.

Every call to an MCP Service follows the same governed path. The agent sends the MCP request to the service's Unity Gateway URL, authenticated with the caller's Databricks identity. The gateway checks that the caller has EXECUTE on the MCP Service. It exposes only the tools you selected and evaluates any attached service policy, which can allow the call, deny it, or require approval. Next the tool runs. A Databricks-provided service runs it with the caller's identity or with managed credentials. For a registered external server, Databricks forwards the request through the HTTP connection and manages the server's credentials. Finally, the call is recorded in system tables for usage monitoring and audit.

Sources567

4.Custom MCP servers: hosting your own tools as a Databricks app

A custom server is the right choice when you already have an MCP server you want to deploy, when you want to run a third-party MCP server as a source of tools, or when the logic is yours alone. Databricks hosts these servers as Databricks apps. The hosting model sets the rules: the server must implement an HTTP-compatible transport, such as the streamable HTTP transport. When deployed, the endpoint is https://<app-url>/mcp, and you pay Databricks Apps pricing.

The quickest start is the built-in template. Go to Compute > Apps > Create app, and under the Agents category select MCP Server - Hello World. Give the app a name that starts with mcp-, because only then does the AI Playground recognize it as an MCP server. The template comes with two example tools. health() confirms the server is running, and get_current_user() shows how to use workspace authentication through the Databricks SDK. To add a tool, define a function with the @mcp.tool() decorator, then redeploy the app.

@mcp.tool()
def uppercase(text: str) -> str:
    """Convert a string to uppercase."""
    return text.upper()

@mcp. ? ()
def uppercase(text: str) -> str:
    """Convert a string to uppercase."""
    return text.upper()

To host a Python MCP server you already have, follow these steps. First, authenticate with OAuth using databricks auth login --host https://<your-workspace-hostname>. Use uv for dependency management: list uv in requirements.txt, and define a script entry point in pyproject.toml (for example, custom-server pointing at server.main:main). Add an app.yaml whose command runs uv run custom-server. Apps listen on port 8000 by default, so set an environment variable override in app.yaml if your server uses a different port. Then create the app with databricks apps create mcp-my-server, sync the source code to the workspace, and run databricks apps deploy.

Sources3

5.Wiring any MCP server into agent code

Once a server exists, connecting to it from agent code looks the same for all three types. The databricks-mcp library handles authentication to Databricks MCP servers, so one client works for managed, MCP Service and custom URLs. First, find out what is available. The docs warn against hardcoding server names, tool names or argument shapes from memory. Every MCP Service exposes a different set of tools, so call list_tools() to get each tool's name, description and input schema at runtime.

from databricks_mcp import DatabricksMCPClient
from databricks.sdk import WorkspaceClient

workspace_client = WorkspaceClient(profile="DEFAULT")
host = workspace_client.config.host

# Use a managed, MCP Service, or custom server URL:
mcp_server_url = f"{host}/api/2.0/mcp/functions/system/ai"

mcp_client = DatabricksMCPClient(server_url=mcp_server_url, workspace_client=workspace_client)
tools = mcp_client.list_tools()
print(f"Available tools: {[t.name for t in tools]}")

This example points at the managed Unity Catalog functions server for system.ai. Running managed system.ai tools requires serverless compute to be enabled in the workspace. The same client also plugs into agent frameworks: McpServer from databricks_openai.agents for the OpenAI Agents SDK, and DatabricksMultiServerMCPClient from databricks_langchain for LangGraph.

What changes from one deployment to another is authentication. Pick the method that matches where the agent runs:

- Local environment: an OAuth profile passed to WorkspaceClient. - Service principal: OAuth client credentials, which you can read from Databricks secrets. When you log the agent, declare DatabricksApps (for custom servers) or the relevant resource so automatic authentication passthrough works. - On-behalf-of-user: the agent acts with the calling user's permissions.

from databricks.sdk.credentials_provider import ModelServingUserCredentials

workspace_client = WorkspaceClient(credentials_strategy=ModelServingUserCredentials())
mcp_client = DatabricksMCPClient(server_url=mcp_server_url, workspace_client=workspace_client)

With on-behalf-of-user authentication, the scopes depend on the server type. For managed servers, you log the agent with the apps scope plus the OAuth scope of each managed server it uses. For an external or built-in MCP Service, you add the ai-gateway user API scope instead, and you grant the calling user EXECUTE on the service. Whichever authentication method you use, a call to an external MCP Service also needs EXECUTE on the service, and AI Gateway enforces that on every call.

Sources2

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Access to a custom MCP server hosted as a Databricks app is controlled with Unity Catalog EXECUTE grants, like an MCP Service.Why is that wrong?

   Custom servers are apps, so Databricks Apps permissions control who can call them. EXECUTE grants apply to MCP Services, which are Unity Catalog securables.

   Covered in Custom MCP servers: hosting your own tools as a Databricks app

2. 2.Any existing MCP server can be deployed as a Databricks app unchanged, whatever transport it uses.Why is that wrong?

   A server hosted as a Databricks app must implement an HTTP-compatible transport, such as streamable HTTP.

   Covered in Custom MCP servers: hosting your own tools as a Databricks app

3. 3.For natural-language business analytics, the Databricks SQL MCP server is the best starting point because the agent can write SQL directly.Why is that wrong?

   The docs recommend starting with Genie One, whose Genie Ontology resolves business terms. Databricks SQL is for running a specific query you have already written.

   Covered in Managed MCP servers: governed access to your Databricks data

4. 4.Tool names and argument shapes are standard across MCP Services, so you can hardcode them in agent code.Why is that wrong?

   Each service exposes different tools. Discover them at runtime with tools/list or DatabricksMCPClient.list_tools().

   Covered in Wiring any MCP server into agent code