list_projects 404s on self-hosted Plane CE — list_lite calls /projects-lite which CE doesn't expose

[OguzKaganAslan]

Environment

• Plane: self-hosted Community Edition (CE)
• plane-mcp-server: 0.2.10
• Transport: stdio, authenticated via Personal Access Token (PAT)

Problem

The list_projects MCP tool always returns a 404, even though the workspace and PAT are valid and other project tools (create/update/delete) work fine against the same workspace.

Root cause

In plane/api/projects.py, Projects.list_lite() (called by the list_projects MCP tool) requests:

GET /api/v1/workspaces/{slug}/projects-lite/

This route does not exist on self-hosted CE and returns 404.

By contrast, Projects.create() (called by the create_project MCP tool, which works correctly) requests:

POST /api/v1/workspaces/{slug}/projects

which returns 200.

Confirmation independent of MCP

Reproduced directly with a raw HTTP call (no MCP involved), using the same PAT:

GET /api/v1/workspaces/{slug}/projects-lite/  → 404 {"error": "Page not found."}
GET /api/v1/workspaces/{slug}/projects/       → 200 (returns paginated project list)

This confirms the 404 is not an auth, membership, or slug issue — the /projects-lite route itself is unavailable on CE, while the plain /projects route works correctly and returns the expected paginated response.

Additional detail

The same SDK class (Projects) already has an unused list() method that targets the working /projects endpoint (as opposed to list_lite()'s /projects-lite). It appears the CE-compatible route is already implemented in the SDK, but the list_projects MCP tool is wired to the incompatible list_lite() method instead.

Suggested fix

• Fall back to /projects when /projects-lite returns 404 (e.g. detect 404 and retry against the list() method), or
• Make the list route configurable/selectable for self-hosted CE instances (since /projects-lite may be a Cloud-only or newer-API-version route not present on CE deployments).

[LorranHippolyte]

Confirming this independently, with a couple of additional data points that might help prioritize/fix it:

Also affects get_workspace_members (via Projects/Members client calling members-lite/), not just list_projects. Same pattern: GET /api/v1/workspaces/{slug}/members-lite/ → 404, GET /api/v1/workspaces/{slug}/members/ → 200 with identical data (minus whatever fields -lite would normally trim).

Not a version issue. We were on self-hosted CE v1.3.0, updated to the latest v1.3.1 (current at the time of writing) specifically to test whether this would resolve — it didn't. Confirmed via docker pull + redeploy, both endpoints still 404 post-update.

Confirmed the -lite routes don't exist anywhere in the open-source codebase. Searched makeplane/plane (the same repo that ships CE) for projects-lite, ProjectLiteEndpoint, MemberLiteEndpoint, etc. — zero matches. Combined with client.py's default PLANE_BASE_URL falling back to https://api.plane.so and the toolset including Cloud/Enterprise-only surfaces (initiatives.py, pql.py), this strongly suggests -lite is Cloud-proprietary and was never intended to exist on CE — so the fix likely can't be "wait for CE to catch up," it has to be client-side (as suggested above: fall back to the unused list()/non-lite methods when -lite 404s, or make it configurable per deployment).

Worked around it locally in the meantime with a ~60-line standalone MCP server hitting /projects/ and /members/ directly, run alongside plane-mcp-server (kept for everything else, which works fine against CE via non-lite routes). Happy to share if useful as a reference, but the real fix belongs here.

[tforsyth-tccc]

Confirming this reproduces on self-hosted Plane Community Edition 1.3.1 with plane-mcp-server 0.2.10 (stdio transport, PLANE_API_KEY + PLANE_WORKSPACE_SLUG auth).

list_projects 404s exactly as described (/projects-lite/ not present on CE). While tracking this down I found the same pattern hits several other "list" tools on this instance, all 404ing while the equivalent plain (non--lite) endpoints work fine via direct API calls with the same credentials:

• list_modules
• list_cycles
• list_work_item_types
• get_workspace_members

retrieve_project, list_labels, and list_states all work fine against the same project, so it's specifically the newer/-lite-style routes that are missing on CE, not an auth or workspace-resolution issue.

Also opened #185 for a related-but-distinct case: create_work_item_relation hits a /dependencies/ route that also 404s on CE, with a working /relations/ fallback identified.

Given how much surface area this covers (and #171 asking whether CE is a supported target), it might be worth treating this as one umbrella "SDK routes missing on self-hosted CE 1.3.1" tracking issue rather than fixing endpoint-by-endpoint.