list_projects 404 on Plane 1.3.1 Community: list_lite() endpoint not found

[willcitizen]

Summary

plane-mcp-server 0.2.10 breaks list_projects against Plane v1.3.1 Community (current stable self-hosted release). The tool returns HTTP 404 on every call. Version 0.2.9 works correctly.

Root cause

0.2.10 changed list_projects in plane_mcp/tools/projects.py to call client.projects.list_lite() which maps to GET /api/v1/workspaces/{slug}/projects/lite/. This endpoint does not exist in Plane 1.3.1 Community and returns 404.

0.2.9 used client.projects.list() → GET /api/v1/workspaces/{slug}/projects/ → 200 OK.

# 0.2.9 (working):
return client.projects.list(workspace_slug=workspace_slug, params=params)

# 0.2.10 (broken on Plane 1.3.1 Community):
return client.projects.list_lite(workspace_slug=workspace_slug, params=params)

The same endpoint gap exists for workspace-wide list_work_items (omitting project_id) which calls client.work_items.list_workspace() → /work-items/ → 404 on 1.3.1.

Verified

• Plane version: v1.3.1 Community (latest stable, confirmed via GET /api/instances/)
• GET /api/v1/workspaces/{slug}/projects/ with API key → HTTP 200, returns all projects ✓
• GET /api/v1/workspaces/{slug}/projects/lite/ → HTTP 404
• Reverting to client.projects.list() resolves the issue

Suggested fix

plane_mcp/tools/projects.py:

from plane.models.projects import PaginatedProjectResponse, Project
from plane.models.query_params import PaginatedQueryParams

def list_projects(...) -> list[Project]:
    params = PaginatedQueryParams(cursor=cursor, per_page=per_page, order_by=order_by)
    response: PaginatedProjectResponse = client.projects.list(workspace_slug=workspace_slug, params=params)
    return response.results

Workaround

Pin to plane-mcp-server==0.2.9 until a fix lands in 0.2.11+.

[willcitizen]

Complete defect inventory — Plane 1.3.1 Community

Running 0.2.10 against Plane 1.3.1 Community (self-hosted, fully current). Original report was just list_projects, but after full toolset audit here is the complete set of broken callers.

(A) 5 _lite callers — all 404 on Plane 1.3.1 Community

Tool	File	Broken call	Working call
list_projects	tools/projects.py:60	client.projects.list_lite()	client.projects.list()
get_project_members	tools/projects.py:344	client.projects.get_members_lite()	client.projects.get_members()
get_workspace_members	tools/workspaces.py:55	client.workspaces.get_members_lite()	client.workspaces.get_members()
list_cycles	tools/cycles.py:67	client.cycles.list_lite()	client.cycles.list()
list_modules	tools/modules.py:60	client.modules.list_lite()	client.modules.list()

All five lite endpoints (e.g. /projects/lite/, /projects/{id}/members-lite/, /workspaces/{slug}/members-lite/, /cycles/lite/, /modules/lite/) return 404 on Plane 1.3.1 Community. The standard endpoints all return 200.

Workaround in our local vendor build: pin to 0.2.9, or swap _lite() → standard calls.

(B) Workspace-wide list_work_items — 404 (endpoint absent)

tools/work_items.py calls client.work_items.list_workspace() when no project_id is given. The /work-items/ workspace-level endpoint doesn't exist in Plane 1.3.1 Community (project-scoped /projects/{id}/issues/ works fine). This is likely a Plane version gap — not necessarily a 0.2.10 regression.

(C) manage_work_item_assignee — pydantic validation error on retrieve

Root cause (confirmed via live test and SDK source inspection):

Plane 1.3.1 Community's GET /projects/{id}/issues/{issue_id}/ returns assignees as a list of UUID strings:

{assignees: [e81acbb1-88ac-4084-bab9-93f05811d144]}

But WorkItemDetail.assignees (in plane/models/work_items.py) is typed as list[UserLite], which requires each element to be a dict/UserLite object. Pydantic v2 strict validation fails:

1 validation error for WorkItemDetail
assignees.0
  Input should be a valid dictionary or instance of UserLite
  [type=model_type, input_value='e81acbb1-88ac-4084-bab9-93f05811d144', input_type=str]

This affects all retrieve_work_item calls for items with any assignees — not just remove-to-empty. manage_work_item_assignee always calls retrieve() first to get the current assignee list, so it fails immediately whenever the item has existing assignees.

Note: WorkItemExpand.assignees (same file) already uses the union type list[str] | list[UserLite] | None and would handle this correctly. The fix would be to update WorkItemDetail.assignees to use the same union type, or to change retrieve() to use WorkItemExpand as the response model.

Workaround in our local vendor build: bypassed with client.work_items._get() raw HTTP call in manage_work_item_assignee, extracting UUIDs from the raw dict.

---

All three categories verified live against Plane 1.3.1 Community (Docker, makeplane/plane-backend:v1.3.1). 0.2.9 clears A without this issue — the lite endpoint variants were introduced in 0.2.10.