MCP networking
Check network access in two directions: from your Model Context Protocol (MCP) client to your workspace, and from your workspace to external MCP servers. For sign-in and identity, see MCP authentication.
Client to workspace
MCP requests must be allowed by your workspace's inbound network controls. If workspace IP access lists are enabled, ask an admin to allow the public IP addresses where the requests originate:
Where the MCP client runs | Addresses to allow |
|---|---|
On your computer, such as Claude Code, Codex CLI, or Cursor | Your network's public outbound IP. If traffic goes through a corporate VPN or proxy, use that network's outbound IP. Ask your network administrator for it. |
In a hosted service, such as a Claude connector or ChatGPT | The provider's published outbound IP ranges. See Claude's outbound IPs and ChatGPT's outbound IPs. |
For hosted clients, browser sign-in comes from your network, while MCP calls come from the provider's servers. Both must be allowed. For example, signing in successfully from your corporate VPN doesn't mean ChatGPT can reach your MCP.
If your organization also uses context-based ingress controls, the requests must satisfy those policies too. Account IP access lists apply to account console and account API access, such as an admin creating an OAuth app.
Workspace to external MCP server
Calls to external MCP providers through Unity Gateway use the workspace's serverless compute plane. This applies to registered external servers and Databricks-provided MCPs for external services.
If your serverless network policy uses Restricted access, add the server's fully qualified domain name (FQDN) to Allowed domains. Start with the host on the MCP's Unity Catalog connection. Check system.access.outbound_network for additional blocked destinations. See Manage network policies and Outbound network logs.
- A Unity Catalog connection doesn't automatically allow its destination.
- Full access is the serverless network policy's mode for allowing outbound internet connections by default. Explicitly blocked domains remain denied. For example, a policy that blocks
mcp.example.comprevents calls to that MCP server. Ask an admin to review the policy's blocked destinations. - To test MCP traffic in dry-run mode, select All products. The Databricks SQL and AI model serving options don't put MCP traffic in dry-run.
Private connectivity
To reach an MCP server in your cloud network, choose how Databricks serverless compute connects to it:
- Private endpoint: Use Private Link to keep traffic on a private connection. An account admin adds a private endpoint rule for the server's domain to a network connectivity configuration (NCC) attached to your workspace. Your cloud administrator approves the endpoint connection. See Configure private connectivity.
- Public endpoint with a firewall: Configure the server's firewall to allow Databricks serverless outbound IPs for your workspace's cloud and region. These IPs are shared across Databricks customers, so keep authentication enabled on the server. See Find the outbound IPs and configure your firewall.
Domains added to private endpoint rules are automatically allowed by network policies, so you don't need to add them separately to Allowed domains. For a public endpoint, follow Workspace to external MCP server.