Skip to content

[feature]: Support reordering modules via API and MCP #9023

Description

@juergen-schadek

Summary

Plane modules expose a sort_order field and the web app can reorder modules manually, but the public API and the official MCP server do not provide a supported way to update module order.

This makes it impossible for integrations or AI agents to persist a manual module order without using browser automation or destructive workarounds.

Current behavior

  • GET /api/v1/workspaces/{workspace_slug}/projects/{project_id}/modules/ returns modules with sort_order.
  • PATCH /api/v1/workspaces/{workspace_slug}/projects/{project_id}/modules/{module_id}/ accepts documented module fields such as name, description, start_date, target_date, status, lead, members, external_source, and external_id.
  • Sending sort_order to the public module PATCH endpoint returns a successful response but does not update the module order.
  • The official Plane MCP server exposes list_modules and update_module, but update_module does not accept sort_order or provide a reorder-specific tool.

Expected behavior

Please support reordering modules through the public API and MCP, either by:

  1. allowing sort_order in the public module update endpoint, or
  2. adding a dedicated module reorder endpoint, for example:
PATCH /api/v1/workspaces/{workspace_slug}/projects/{project_id}/modules/{module_id}/reorder/

with a payload such as:

{
  "sort_order": 15535.0
}

The official MCP server could then expose this as either:

update_module(..., sort_order=...)

or a dedicated tool:

reorder_module(project_id, module_id, sort_order)

Why this should be worked on

Plane already treats module order as a first-class value in reads and in the web UI. Exposing the same capability through the public API would make module ordering automation possible for migrations, sync tools, scripts, and MCP-based agents.

Without this, integrations can list modules in manual order but cannot persist a new manual order safely. The only alternatives are browser automation or destructive workarounds such as recreating modules, which changes module IDs and risks data loss.

Example use case

An automation agent reads a project's modules and wants to arrange them in a meaningful manual order, for example:

  1. Health
  2. Finances
  3. Career
  4. Personal development
  5. Family and friends
  6. Romantic relationships
  7. Fun and recreation
  8. Physical environment

The agent can compute the intended order but cannot persist it via API/MCP today.

Activity

  1. faizansaiyed123 commented on Oct 8, 2026

    @faizansaiyed123

    Hi! I’d like to work on this issue.

    I’ve verified that the current public API still does not accept or persist sort_order on module updates, and there is no open PR or existing discussion from another contributor on this issue. I’ll keep the change focused on exposing module reordering through the supported API/MCP path, with contract coverage for updating and persisting the order.

    I’ll first align the API contract with the existing module ordering behavior, then cover the integration surface without changing unrelated module functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions