Feature: Add project membership management tools

[davgordo]

Summary

Plane MCP currently exposes project-membership reads through get_project_members, but it exposes no tools for adding, updating, reactivating, or removing project memberships.

This creates a significant automation gap: an MCP agent can create and inspect a project, but it cannot grant existing workspace users access to that project.

Environment

• Plane MCP Server package: 0.2.9
• Container image: makeplane/plane-mcp-server:v0.2.9
• Python: 3.11
• OS: Linux x86_64
• Plane deployment: self-hosted
• MCP client: standalone curl reproduction
• Transport: Streamable HTTP with PAT authentication
• Negotiated MCP protocol: 2025-03-26
• curl: 8.18.0
• jq: 1.8.1

The MCP initialization response reported server version 3.2.0; this appears to be the FastMCP version rather than the Plane MCP package version.

Use case

An automated agent:

1. Creates a new Plane project.
2. Finds existing users in the workspace.
3. Needs to grant those users project access with appropriate project roles.
4. Continues creating and assigning work inside the project.

Steps 1 and 2 are possible through MCP, but step 3 requires manual interaction through the Plane UI or a separate direct API integration.

For private projects, this prevents an MCP-driven workflow from completing project setup autonomously.

Minimal reproduction

plane-mcp-membership-reproduction.tar.gz

Extract it:

tar -xzf plane-mcp-membership-reproduction.tar.gz
cd issue-artifacts-membership.*

Supply runtime values through environment variables:

read -rsp 'Plane API token: ' PLANE_API_TOKEN
echo
export PLANE_API_TOKEN

read -rp 'Plane MCP endpoint: ' PLANE_MCP_URL
export PLANE_MCP_URL

read -rp 'Workspace slug: ' PLANE_WORKSPACE_SLUG
export PLANE_WORKSPACE_SLUG

read -rp 'Existing project UUID: ' PROJECT_ID
export PROJECT_ID

export PLANE_MCP_VERSION='0.2.9'

Run:

./reproduce-membership-gap.sh

The script:

1. Initializes an MCP session.
2. Reads the MCP tool inventory.
3. Confirms that get_project_members exists.
4. Successfully invokes get_project_members.
5. Searches the tool inventory for project-membership mutation operations.
6. Stores only tool definitions and response-shape metadata.

It stores no credentials, URLs, workspace identifiers, project identifiers, project names, or member data in the resulting artifacts.

Actual behavior

The reproduction produced:

Read tool: get_project_members
Read call succeeded: true
Membership-related tools: get_project_members
Membership mutation tools: (none)
Membership mutation tool count: 0

The read operation returned a valid array, confirming that project membership is accessible through the MCP server.

No tool name matched an add, create, update, remove, delete, or manage operation for project membership.

The attached bundle includes:

membership-related-tools.json
membership-mutation-tools.json
summary.json
summary.txt

Expected capability

The MCP server should support at least the following project-membership operations:

• Add one or more existing workspace users to a project.
• Assign a project role when adding a member.
• Change an existing project member’s role.
• Reactivate an inactive project membership.
• Remove a user from a project.
• Return clear errors for insufficient permissions, invalid users, and users who are not workspace members.

Bulk addition would be particularly useful because project setup commonly involves adding an entire initial team.

Possible tool design

One possible design would use separate tools:

add_project_members
update_project_member
remove_project_member

For example:

{
  "project_id": "<project-uuid>",
  "members": [
    {
      "member_id": "<workspace-user-uuid>",
      "role_id": "<project-role-uuid>"
    }
  ]
}

Updating a membership could accept:

{
  "project_id": "<project-uuid>",
  "membership_id": "<project-membership-uuid>",
  "role_id": "<project-role-uuid>"
}

Removal could accept:

{
  "project_id": "<project-uuid>",
  "membership_id": "<project-membership-uuid>"
}

A consolidated tool such as manage_project_members would also be reasonable and may fit the repository’s preference for combining closely related add/remove operations. The exact names and models should follow the current Plane SDK and existing repository conventions.

Supporting a project role slug in addition to a role UUID could make the operation easier and more reliable for agents, provided it can be resolved unambiguously.

Desired behavior

• Adding a workspace user creates or activates the project membership.
• Adding an existing active member is idempotent or returns a clear “already a member” result.
• Updating a member changes the project role without recreating the membership.
• Removing a member removes or deactivates project access according to Plane’s API semantics.
• Results are compact and include the membership ID, member ID, role, and active status.
• Permission and validation errors are returned in a form an MCP client can act upon.

Suggested tests

• Add one existing workspace user.
• Bulk-add multiple workspace users.
• Add a user who is already an active project member.
• Reactivate an inactive membership.
• Change a project member’s role.
• Remove a project member.
• Attempt to add a user who is not a workspace member.
• Attempt mutation without sufficient permissions.
• Verify that the resulting membership appears through get_project_members.

Related but distinct: #129 describes projects becoming inaccessible when the authenticated user is not a project member. Membership mutation tools would allow an authorized agent to prevent or repair that class of access problem during project setup.