Skip to main content

Govern an MCP service

This page describes how to govern an MCP Service with the same Unity Catalog primitives that protect your other securables: limit which tools the service exposes, apply service policies to allow or deny individual calls, set rate limits, and monitor usage. These controls apply to both MCP Services you register and Databricks-provided MCP Services.

Select which tools are exposed​

By default, an MCP Service makes available all of the tools the MCP server provides. To make available only a subset, select the tools when you create the MCP Service, or update the selection later. Each selector is matched against tool names: a pattern ending in * is a prefix match (get_* matches get_me and get_issue), and any other value is an exact match (search_repositories matches only that tool).

In the create flow, under Tools:

  • Select Select manually to select each tool individually.
  • Select Advanced to enter selection patterns, using the prefix and exact-match rules described above.
  • Turn on Automatically include tools added to this server in the future to make new tools available as the MCP server adds them.

Tools that you don't select don't appear in tools/list, and the MCP Service rejects a tools/call for an unselected tool:

JSON
{ "code": -32003, "message": "Tool not allowed by MCP service configuration." }

Apply a service policy​

Beta

Service policies are in Beta. Unity Gateway is generally available, but its beta capabilities are enabled separately. An account admin must turn on the Unity Gateway beta features from the account console Previews page. See Manage Databricks previews.

A service policy evaluates each tool call before it runs (the input phase, ON CALL) and, optionally, its result (the output phase, ON RESULT). A policy can allow, deny, or require human approval for the request—for example, to block destructive operations or block calls that contain PII—without changing which tools are available. Service policies are part of AI governance in Unity Catalog.

To write a policy function and attach it to an MCP Service, see Service policies for AI securables and Create and attach a service policy.

Control access to third-party providers​

Any MCP Service that connects to a third-party application provider is governed at two independent layers. The network layer controls whether a connection to the provider can be established. The privilege layer controls whether a user can access the provider through the MCP Service.

This applies to external MCP servers you register and to Databricks-provided connected applications such as Slack, GitHub, Atlassian, Google, and Microsoft 365. Use both layers together to control who can reach an external provider and which providers are reachable at all.

Control which providers a service can connect to​

An MCP Service connects to the provider's API or MCP server through Unity Gateway. These external requests are subject to serverless egress control. With a Restricted access network policy, outbound connections are denied by default. An MCP Service can then reach a public provider only if the provider's domain is an allowed destination in the policy. Destinations reached privately over Private Service Connect are implicitly allowed.

This gives you a default-off posture for external MCP Services without per-service settings. A provider that isn't allowed in the network policy is blocked at the network layer, even for a user who holds EXECUTE on the service. To allow or block a provider, and to find every destination a service needs, see Allow an MCP server in a network policy.

Control who can invoke the service​

An MCP Service is a Unity Catalog securable. A user can invoke the tools provided by the MCP Service only if they hold EXECUTE on the service. They also need USE CATALOG and USE SCHEMA on its parent catalog and schema. To restrict access:

  • Grant these privileges only to approved users or groups instead of broadly on the schema that contains the service.
  • Review and revoke any existing broad schema-level grants that would otherwise leave the service callable. For Databricks-provided services, check for a default grant on the system.ai schema.
  • Optionally, use ABAC GRANT policies to grant EXECUTE dynamically from governed tags, so that only approved services are allowed and any added later are automatically excluded.

Combine these grants with service policies to allow, deny, or require approval for individual tool calls.

note

Serverless egress control and Unity Catalog governance are independent, complementary layers. A Unity Catalog grant does not open a network path, and adding a provider to a network policy does not grant Unity Catalog permission on a service. Creating a Unity Catalog connection does not automatically allow its destination in a restricted-access network policy. Implicit allowlisting for Unity Catalog connections is deprecated; accounts that used it before deprecation keep it for a limited transition period. Use both layers together for defense in depth.

Set rate limits​

Limit how frequently agents can call an MCP Service to control cost and protect the external server. See Apply rate limits to model and MCP services.

Monitor usage​

Unity Gateway records activity for every MCP Service in Unity Catalog system tables:

  • Usage: call volume, errors, and latency in system.ai_gateway.usage (filter service_type = 'MCP_SERVICE'). See Track model usage.
  • Audit: control-plane changes (createMcpService, updateMcpService, deleteMcpService) and each invocation (mcpCall) in system.access.audit. See Audit log system table reference.
  • Traces: tool-call requests, responses, and policy decisions are captured by trace logging, which is enabled once at the account level and shared across all MCP Services.
  • Dashboard: external MCP server traffic appears in the built-in Unity Gateway usage dashboard. See Built-in usage dashboard.

For all Unity Catalog system tables, see System tables reference. For an overview of governing AI traffic, see AI governance in Unity Catalog.

Next steps​