# Members and Permissions with NocoDB MCP

> Part of the NocoDB documentation (MCP Server). Index of all pages: https://nocodb.com/llms.txt. Any docs page is available as Markdown by adding `.md` to its URL.

URL: https://nocodb.com/docs/mcp/permissions
Last updated: 2026-10-22

NocoDB MCP tools for access: project and workspace members and teams, table and field permissions, row-level security policies and the audit log.

An MCP client can manage who can do what in your NocoDB projects and workspaces, and read who changed what.

These 24 tools are in the **Access & security** section of [Tools & Permissions](/docs/mcp/connections#connection-tools-and-access). A tool needs the access level in its row: **Read**, **Read & write**, or **Read, write & delete**.

## How the assistant works with members & permissions

For a project: list the members and the teams that have a role on the project, and give, change, or remove the role of a person or a team. For a workspace: list the members and teams, invite people, change a workspace role, and remove a person.

Set table permissions, field permissions, and Record-Level Security policies.

Read the change history of one record. Project owners can also read the audit log of a full project, filtered by user, event type, or date range.

<Callout type="info">
  Tools respect the token owner's project role: viewers can read, editors can write records, views, filters, and sorts, and creators can change schema. Some tools in this section need a higher role or a feature on the workspace plan. See 

  [Availability](#availability)

  . Record-Level Security policies apply to MCP requests.
</Callout>

## Tools

### Members and teams

The member and team tools are on connections that you create in **Account Settings** and on connections pinned to one project. A connection pinned to one project has no workspace tools: `listWorkspaceTeams`, `listWorkspaceMembers`, `inviteWorkspaceMembers`, `updateWorkspaceMember` and `removeWorkspaceMember`. The team tools need team management on the workspace plan.

| Tool                     | What it does                                                                    | Access level         |
| ------------------------ | ------------------------------------------------------------------------------- | -------------------- |
| `listWorkspaceTeams`     | List the teams in a workspace: the ids addBaseTeam takes.                       | Read                 |
| `listWorkspaceMembers`   | List the members of a workspace and their workspace role.                       | Read                 |
| `addBaseMembers`         | Give people a role on this project by email.                                    | Read & write         |
| `updateBaseMember`       | Change one member's role on this project.                                       | Read & write         |
| `addBaseTeam`            | Give a team a role on this project.                                             | Read & write         |
| `updateBaseTeam`         | Change a team's role on this project.                                           | Read & write         |
| `inviteWorkspaceMembers` | Invite people to a workspace by email, all at one role.                         | Read & write         |
| `updateWorkspaceMember`  | Change one member's workspace role.                                             | Read & write         |
| `removeBaseMember`       | Remove one member's explicit role on this project.                              | Read, write & delete |
| `removeBaseTeam`         | Remove a team's role on this project.                                           | Read, write & delete |
| `removeWorkspaceMember`  | Remove someone from a workspace, along with their roles on every project in it. | Read, write & delete |

### Table and field permissions

The permission tools need the **Creator** or **Owner** role on the project. `setPermission` and `dropPermission` also need table and field permissions on the workspace plan. `listPermissions` works on every plan, so a workspace on a lower plan can still see its grants.

| Tool              | What it does                                                                                                               | Access level         |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------- | -------------------- |
| `listBaseMembers` | List the users, teams, agents and roles of this project: the subjects a permission grant or RLS policy can be assigned to. | Read                 |
| `listPermissions` | List permission grants configured in this project.                                                                         | Read                 |
| `setPermission`   | Create or replace a permission grant on a table or field.                                                                  | Read & write         |
| `dropPermission`  | Remove a permission grant, so the entity falls back to plain project-role access.                                          | Read, write & delete |

### Row-level security

The row-level security tools need the **Owner** role on the project. The **Creator** role is not enough. The tools also need row-level security on the workspace plan.

| Tool                     | What it does                                                                        | Access level         |
| ------------------------ | ----------------------------------------------------------------------------------- | -------------------- |
| `listRlsPolicies`        | List row-level security policies of a table, each with its subjects and conditions. | Read                 |
| `getRlsPolicy`           | Get a single row-level security policy by ID.                                       | Read                 |
| `createRlsPolicy`        | Create a row-level security policy.                                                 | Read & write         |
| `updateRlsPolicy`        | Update a policy's title, enabled state, order, or default behaviour.                | Read & write         |
| `setRlsPolicySubjects`   | Replace the set of subjects a policy applies to.                                    | Read & write         |
| `setRlsPolicyConditions` | Replace all conditions of a policy.                                                 | Read & write         |
| `deleteRlsPolicy`        | Delete a row-level security policy and its conditions.                              | Read, write & delete |

### Audit log

`listRecordAudits` works for every project role. `listBaseAudits` needs the **Owner** role on the project and workspace audit logs on the workspace plan. On NocoDB Cloud, the workspace plan also sets how far back each audit log goes.

| Tool               | What it does                                                                                               | Access level |
| ------------------ | ---------------------------------------------------------------------------------------------------------- | ------------ |
| `listRecordAudits` | The change history of one record: who changed which field, from what to what, and when.                    | Read         |
| `listBaseAudits`   | The audit log of the whole project: schema and record changes across every table, newest first by default. | Read         |

## Good to know

* A connection cannot give a role above the role you hold.
* A connection cannot lower your own access. It cannot remove you from a project or a workspace, lower your own project role or workspace role, or invite you to a project at a lower role.
* `removeWorkspaceMember` needs the **Creator** role or above on the workspace. It cannot remove the last owner, the only owner of a team, a user that SCIM manages, or a member with a role above yours.
* An explicit project role always wins over an inherited role. For example, if you give a workspace creator the **Viewer** role on a project, that person is a viewer on that project.
* Renaming a project and changing its icon color are the only project settings a connection can write.

## Availability

A connection lists every tool in this section, including the tools that your role or the workspace plan does not cover. NocoDB checks the role and the plan when the tool runs. If the check fails, the tool returns an error.

| Tools                                                                                              | Project role                       | Workspace plan              |
| -------------------------------------------------------------------------------------------------- | ---------------------------------- | --------------------------- |
| `listBaseMembers`, `addBaseMembers`, `updateBaseMember`, `removeBaseMember`                        | Same as in the app                 | Every plan                  |
| `listWorkspaceTeams`, `addBaseTeam`, `updateBaseTeam`, `removeBaseTeam`                            | Same as in the app                 | Team management             |
| `listWorkspaceMembers`, `inviteWorkspaceMembers`, `updateWorkspaceMember`, `removeWorkspaceMember` | Workspace role, same as in the app | Every plan                  |
| `listPermissions`                                                                                  | Creator or Owner                   | Every plan                  |
| `setPermission`, `dropPermission`                                                                  | Creator or Owner                   | Table and field permissions |
| Row-level security tools                                                                           | Owner                              | Row-level security          |
| `listRecordAudits`                                                                                 | Every role                         | Every plan                  |
| `listBaseAudits`                                                                                   | Owner                              | Workspace audit logs        |

<Callout type="note">
  An older OAuth connection made for one project works differently. It does not list the tools that your role or the workspace plan does not cover, and it has no member or team tools.
</Callout>

## Related

* [Connections and access](/docs/mcp/connections)
* [NocoDB MCP Server overview](/docs/mcp)

---

## Related pages

- [NocoDB MCP Server](https://nocodb.com/docs/mcp.md): The NocoDB MCP server lets Claude, ChatGPT, Claude Code, Cursor and other AI assistants work with your NocoDB data through 200 tools, with OAuth or a token.
- [MCP Connections and Access](https://nocodb.com/docs/mcp/connections.md): Create a NocoDB MCP connection, choose the projects it can reach and the tools it can call, and authorize web clients such as Claude and ChatGPT with OAuth.
- [Records and Data with NocoDB MCP](https://nocodb.com/docs/mcp/records.md): NocoDB MCP tools for records: query, aggregate, create, update and delete records, link them, add attachments and comments, import and export CSV.
- [Tables and Fields with NocoDB MCP](https://nocodb.com/docs/mcp/schema.md): NocoDB MCP tools for structure: create and change tables, fields and select options, folders and duplicates, with a dry run before risky field changes.
- [Views with NocoDB MCP](https://nocodb.com/docs/mcp/views.md): NocoDB MCP tools for views: create and configure views, filters and sorts, share links, form field conditions, view folders, row coloring and date dependencies.
- [Workflows and Automation with NocoDB MCP](https://nocodb.com/docs/mcp/automation.md): NocoDB MCP tools for automation: build workflows step by step, test steps without running them, publish, and manage webhooks, scripts and automation folders.
- [Classic Apps, Dashboards and Docs with NocoDB MCP](https://nocodb.com/docs/mcp/apps-and-docs.md): NocoDB MCP tools for classic apps (interfaces), dashboards and widgets, and documents: create, configure, publish and share them through an AI assistant.
- [NocoDB Skills](https://nocodb.com/docs/mcp/skills.md): Use the NocoDB skill for Claude to list, create, update and delete NocoDB tables, fields, views and records through natural language with an API token.