Skip to main content
Glama

Manage Unity Catalog grants

manage_uc_grants
Destructive

Show, grant, and revoke Unity Catalog privileges on any securable, including inherited grants.

Instructions

Show, grant and revoke Unity Catalog privileges on any securable (catalog, schema, table/view, volume, function, external_location, storage_credential, connection, share, metastore, ...).

get returns direct grants, get_effective includes privileges inherited from parents. grant/revoke require principal + privileges and always show the principal's before/after direct privileges in the plan. ALL_PRIVILEGES is rejected unless allow_all_privileges=true; grants to 'account users' are flagged.

Safety classification: get, get_effective = READ_ONLY+SECURITY_SENSITIVE; grant = SECURITY_SENSITIVE+WRITE; revoke = DESTRUCTIVE+SECURITY_SENSITIVE.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesget: direct grants; get_effective: incl. inherited; grant / revoke privileges.
confirmNoSet to true ONLY after the user has reviewed the plan returned by a previous call with status 'confirmation_required'. Required for destructive/security-sensitive actions.
dry_runNoIf true, validate and return the planned change without executing it.
full_nameYesFull name of the securable, e.g. 'main.sales.orders' (metastore: the metastore id).
page_sizeNoMax items to return (server caps this).
principalNoUser email, group name or service principal application id. Required for grant/revoke; optional filter for get.
page_tokenNonext_page_token from a previous response.
privilegesNoPrivileges for grant/revoke, e.g. ['SELECT', 'USE_SCHEMA'] (spaces allowed: 'USE CATALOG').
securable_typeYesSecurable type: agent_service, catalog, clean_room, connection, credential, external_location, external_metadata, function, mcp_service, metastore, model, model_provider_service, model_service, pipeline, provider, recipient, schema, share, skill, staging_table, storage_credential, table, volume. Views use 'table'.
allow_all_privilegesNoMust be true to grant ALL_PRIVILEGES.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
pageNo
planNo
toolYes
actionNo
safetyNo
statusNosuccess
summaryYes
warningsNo
next_stepsNoSuggested follow-up calls.
request_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the coarse annotations: per-action safety classification (get/get_effective READ_ONLY, grant WRITE, revoke DESTRUCTIVE), the requirement that grant/revoke echo the principal's before/after direct privileges in a plan, the ALL_PRIVILEGES gating via allow_all_privileges, and the 'account users' flag. This refines the global destructiveHint=true into actionable per-action behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the scope and action semantics, then the behavioral/safety constraints. Dense but every clause carries distinct, non-redundant information (action semantics, gating rules, safety classification) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is unnecessary, and the description covers the confirmation/dry-run safety flow and privilege gating. It omits any mention of pagination behavior (page_size/page_token) or the inherited-vs-direct distinction for mutating actions, which is a minor gap for a 10-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description reinforces cross-parameter constraints (principal+privileges required for grant/revoke; ALL_PRIVILEGES rejected unless allow_all_privileges) but largely restates what the schema property descriptions already say, adding little new syntax or format detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb set (show/grant/revoke) and resource (Unity Catalog privileges on any securable), and enumerates the securable types so an agent knows the blast radius. It clearly distinguishes its four internal actions (get vs get_effective vs grant vs revoke), which is the key ambiguity for this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance for the internal actions (get for direct, get_effective for inherited, grant/revoke require principal+privileges) and the confirmation workflow. It does not, however, differentiate this tool from siblings like manage_uc_sharing, manage_uc_security_policies, or manage_uc_tags, leaving some routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.