Members and Permissions with NocoDB MCP

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. 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.

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. Record-Level Security policies apply to MCP requests.

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

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.