Σημείωμα
Η πρόσβαση σε αυτήν τη σελίδα απαιτεί εξουσιοδότηση. Μπορείτε να δοκιμάσετε να εισέλθετε ή να αλλάξετε καταλόγους.
Η πρόσβαση σε αυτήν τη σελίδα απαιτεί εξουσιοδότηση. Μπορείτε να δοκιμάσετε να αλλάξετε καταλόγους.
Check network access in two directions: inbound, from your Model Context Protocol (MCP) client to your workspace, and outbound, from your workspace to external MCP servers. For sign-in and identity, see MCP authentication.
Client to workspace (inbound)
MCP requests must be allowed by your workspace's inbound network controls. The following table shows what to allow for each type of client and inbound control:
| Context-based ingress (recommended) | Front-end Private Link with public access disabled | |
|---|---|---|
| MCP client runs in a hosted service, such as ChatGPT or a Claude connector | Add ChatGPT or Claude as a partner platform. Azure Databricks keeps the IP ranges current. | Hosted clients can't connect. Keep public access enabled and restrict it with context-based ingress. |
| MCP client runs on your computer, such as Claude Code, Codex CLI, or Cursor | Allow your network's public outbound IP. | Connect through the private endpoint. |
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.
Allow clients with context-based ingress (recommended)
To secure inbound network access to your workspace while still allowing MCP clients to connect, Azure Databricks recommends using context-based ingress controls:
- Hosted clients: Add ChatGPT or Claude as a partner platform in a workspace context-based ingress policy. Azure Databricks syncs the provider's published IP ranges, so you don't maintain them yourself. See Allow partner platforms in context-based ingress policies.
- Clients on your computer: Add a rule that allows 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 enforced mode, context-based ingress blocks requests that don't match an allow rule. Allowed requests must still be authenticated, and they run with the permissions of the authenticated user or service principal that made them.
Front-end Private Link
If your workspace uses front-end Private Link with public access disabled, MCP clients on your computer can connect, but MCPs in hosted clients, such as ChatGPT and Claude connectors, are blocked.
To allow these clients and still limit public access, enable public access and restrict it with a context-based ingress policy that allows them as partner platforms.
Workspace IP access lists
If your workspace still enforces workspace IP access lists, they're evaluated together with context-based ingress, and a request must be allowed by both. A partner platform rule isn't enough while an IP access list blocks the provider's IPs. Migrate your IP access lists to context-based ingress and turn off their enforcement. See Migrate workspace IP access lists to context-based ingress.
Note
If you can't migrate yet, add the provider's published IP ranges to your IP access list. See Claude's outbound IPs and ChatGPT's outbound IPs. For clients on your computer, add your network's public outbound IP. Providers change their IP ranges, so update the list when they do.
Account IP access lists
Account IP access lists apply to account console and account API access, such as an admin creating an OAuth app. They don't apply to MCP calls to your workspace.
Workspace to MCP server (outbound)
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. Serverless egress control determines which destinations serverless compute can reach.
MCP servers on the public internet
If serverless egress control for your workspace 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. See Manage network policies for serverless egress control.
- A Unity Catalog connection doesn't automatically allow its destination.
- With Full access, serverless compute can reach internet destinations by default, but explicitly blocked domains remain denied. For example, blocking
mcp.example.comprevents calls to that MCP server. Ask an admin to review the 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.
MCP servers in your cloud network
To reach an MCP server in your cloud network, choose how Azure 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 Azure Databricks serverless outbound IPs for your workspace's cloud and region. These IPs are shared across Azure Databricks customers, so keep authentication enabled on the server. See Configure access to other resources using outbound IP addresses.
Serverless egress control automatically allows domains in private endpoint rules that specify domain names, so you don't need to add them to Allowed domains. For a public endpoint, follow MCP servers on the public internet.
Troubleshoot blocked requests
Use the network access system tables to find which rule blocked a request:
- Inbound: Query
system.access.inbound_networkfor requests that an ingress policy denied. See Inbound network access events. - Outbound: Query
system.access.outbound_networkfor destinations that serverless egress control blocked. See Outbound network access events.
Common causes:
- Sign-in works, but MCP calls fail from a hosted client: The provider's IP ranges aren't allowed. Add the provider as a partner platform, or add its IP ranges to your IP access list.
- A partner platform rule is in place, but requests are still blocked: Workspace IP access lists are still enforced and don't include the provider's IPs. See Workspace IP access lists.
- A hosted client can't reach a workspace with front-end Private Link: Public access is disabled. Enable public access and restrict it with context-based ingress.
- Calls to an external MCP server fail: The server's domain isn't in Allowed domains, or it's explicitly blocked.