checkRoleAccess

Answer whether one role holds privileges on one table, view, sequence, function or procedure -- as PostgreSQL evaluates it, via has_table_privilege and its relatives, so role inheritance, grants to PUBLIC, ownership and superuser are all folded in the way the server folds them…

read-onlyany connectionsweeps instancesweeps group

Synopsis

checkRoleAccess(grantee, object, schema)

Description

Answer whether one role holds privileges on one table, view, sequence, function or procedure -- as PostgreSQL evaluates it, via has_table_privilege and its relatives, so role inheritance, grants to PUBLIC, ownership and superuser are all folded in the way the server folds them rather than reconstructed from ACLs. Needs no grant of its own: these functions and the catalog are world-readable, so any role that can connect may ask about any other.

Returns schema USAGE and database CONNECT beside the object privileges, because a grant on the table is inert without them and the resulting error names the table. Where a table-level privilege is absent but individual columns carry it, the columns are listed. IMPORTANT: has_table_privilege does not consider row-level security, so a true here can still return no rows -- row_level_security carries whether RLS is on, whether this role is subject to it (the owner is exempt unless FORCE ROW LEVEL SECURITY), and every policy with whether it applies to this role.

RLS enabled with no applicable permissive policy denies everything. Not to be confused with checkPrivileges, which reports which of THIS SERVER's operations the CONNECTING role can run.

Parameters

grantee requiredstring

the role to ask about; need not be the role this server connects as, and need not hold an actual GRANT -- ownership and superuser answer true too. Named grantee rather than role because role is reserved server-wide for narrowing a sweep to a primary or a replica

object requiredstring

table, view, sequence, function or procedure name. A routine name reports every overload

schema requiredstring

Also accepts connection, instance, group, described once under arguments every tool takes.

Output

Whether one role holds privileges on one object, as PostgreSQL itself evaluates it. An absent extension or a missing grant is reported as {error, hint} instead.

Scope

A physical replica is byte-identical here, so asking each member of a replication group adds nothing.

Example mocked data

Request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "checkRoleAccess",
    "arguments": {
      "grantee": "reporting",
      "schema": "shop",
      "object": "orders"
    }
  }
}

Result

{
  "role": {
    "name": "reporting",
    "exists": true,
    "can_login": true,
    "superuser": false,
    "inherits": true,
    "bypass_rls": false,
    "member_of": []
  },
  "object": {
    "schema": "shop",
    "name": "orders",
    "kind": "table",
    "owner": "migrator",
    "is_owner": false
  },
  "database_access": {
    "connect": true
  },
  "schema_access": {
    "usage": true,
    "create": false
  },
  "privileges": {
    "SELECT": true,
    "INSERT": false,
    "UPDATE": false,
    "DELETE": false
  },
  "columns": {},
  "row_level_security": {
    "enabled": false,
    "forced": false,
    "applies_to_role": false,
    "policies": []
  },
  "overloads": null,
  "note": "SELECT is granted directly, and row-level security is not enabled, so every row is readable."
}

Invented values on a fictional shop database, shaped by and checked against this tool's output schema. Real output is returned as structuredContent to clients that negotiate MCP 2025-06-18 or later.

See also

checkPrivileges, roleDependencies, defaultPrivileges