For the complete documentation index, see llms.txt. This page is also available as Markdown.

Patch Project Members

Description

Adds, updates or removes the direct members of an existing AttackForge project - the users added to the project one by one, each with an access level, a project role and email notification settings. This is a write operation.

One call can mix up to 50 operations, one per user; the call is refused without changing anything if any operation cannot be applied. A user is added by user_id (source: find_users) or by the email address of an existing user; adding a current member updates them, and adding a former member restores them. Read the current members with find_project_members. Members who reach the project through a linked group are managed with patch_project_groups instead.

The shape of args is declared inline (see Building args for Write Tools), so no preparatory call is needed.

Preconditions: the caller must be an Admin, the project's owner, a Project Coordinator with access to the project, or a member admin of the project (see patch_project_member_admins); a member admin who is not a Project Coordinator cannot grant an access level above their limit. As in the AttackForge UI, a newly added member is emailed, and a member whose project role changes is emailed when the project and their notification settings allow it. On success the user ids are returned, sorted by outcome.

How To Enable

  1. Go to Users

  2. Select the user you would like to provide access to this tool

  3. Click on Access > MCP

  4. Click on Add Tools

  5. Select the tool patch_project_members and click Add

Example Prompts

  • Add jane.smith@acme.example to project X as a Pentester with Edit access.

  • Give Bob Upload access on the ACME project.

  • Change Jane's project role to Pentest Lead.

  • Remove the contractors from this project.

  • Turn off emails for Bob on project X.

Parameters

Parameter
Type
Required
Description

args

object

Yes

The project-members patch payload - see the keys below.

args keys:

Key
Type
Required
Description

project_id

string

Yes

Id (24-hex) of the project whose members are changed. Source: find_projects.

operations

array

Yes

1 to 50 operations, at most one per user - see the keys below.

operations item keys:

Key
Type
Required
Description

type

string

Yes

'add', 'update' or 'remove'.

user_id

string

No

Id (24-hex) of the user. Required for 'update' and 'remove', which need a current direct member (source: find_project_members, its user_id field). For 'add', give user_id or email but not both; the user must exist and not be deleted (source: find_users).

email

string

No

'add' only, in place of user_id: the email address of an existing, non-deleted user, matched case-insensitively. A new user cannot be invited this way, and an address held by more than one user is refused.

access_level

string

No

'View' can read the project, 'Upload' can also upload files, 'Edit' can also change it. Required for 'add'. It cannot exceed the caller's own member admin limit; Admins, the project's owner and Project Coordinators with access to the project are not limited.

project_role

string

No

The member's project role. Required for 'add'. It must be one of the tenant's project roles, which get_args_schema_for_tool(tool="create_project") lists as the enum of access.team_members[].project_role; an unknown role is refused with the list. The role a member already holds is accepted even if it has since left that list.

notifications

array

No

The project emails the member receives: 'All Emails', 'No Emails', or individual events ('Daily Start/Stop Testing', 'New Critical Vulnerability', 'New High Vulnerability', 'New Medium Vulnerability', 'New Low Vulnerability', 'New Info Vulnerability', 'Project Role Updated', 'Project On-Hold/Off-Hold', 'Retest Completed', 'Vulnerability Ready For Retesting', 'Vulnerability Re-Opened', 'Vulnerability Closed'). Replaces the member's current list. Defaults to ['All Emails'] for a user who has never been a member; a restored former member keeps their earlier list.

An 'update' must supply at least one of access_level, project_role or notifications, and changes only those. 'remove' takes only user_id. unchanged lists the members that already had the settings asked for - it is not an error and the call should not be retried.

Example Response

Last updated