list_projects and get_workspace_members call Cloud-only *-lite endpoints → HTTP 404 on self-hosted Community Edition

[DavidPivert]

Summary

On a self-hosted Plane Community Edition instance, list_projects and get_workspace_members always fail with HTTP 404: Not Found, even though authentication is valid and every other tool works. The root cause is that these two tools call the *-lite SDK variants, which hit endpoints (/projects-lite/, /members-lite/) that do not exist in Community Edition. The standard, non-lite endpoints (/projects/, /members/) are present and return 200.

This effectively breaks project/member discovery for every self-hosted CE user — which is often the first thing an agent calls before doing anything useful.

Environment

• plane-mcp-server: v0.2.11 (installed from the v0.2.11 git tag)
• plane-sdk: 0.2.20
• Plane instance: Community Edition v1.3.1 (latest CE at time of writing), self-hosted via Docker Compose
• Transport: stdio
• Auth: X-API-Key (PAT), PLANE_BASE_URL = instance origin (no /api suffix), valid PLANE_WORKSPACE_SLUG

Reproduction

Call list_projects (no args) against a self-hosted CE workspace:

Error: HTTP 404: Not Found: Page not found.

Same for get_workspace_members.

Meanwhile retrieve_project, create_work_item, list_work_items, etc. (anything scoped by an explicit project_id) all succeed against the same instance with the same credentials — so it is not auth, not the base URL, and not the workspace slug.

Root cause

The two failing tools call the *-lite SDK methods:

• plane_mcp/tools/projects.py → list_projects calls client.projects.list_lite(...)
• plane_mcp/tools/workspaces.py → get_workspace_members calls client.workspaces.get_members_lite(...)

In plane-sdk (plane/api/projects.py, plane/api/workspaces.py) those resolve to:

• list_lite() → GET /api/v1/workspaces/{slug}/projects-lite/
• get_members_lite() → GET /api/v1/workspaces/{slug}/members-lite/

The SDK also exposes the non-lite equivalents, which CE serves:

• list() → GET /api/v1/workspaces/{slug}/projects/
• get_members() → GET /api/v1/workspaces/{slug}/members/

Evidence (direct curl against the same instance, same PAT)

Endpoint	HTTP
GET /api/v1/workspaces/{slug}/projects/	200 (returns all projects)
GET /api/v1/workspaces/{slug}/projects-lite/	404
GET /api/v1/workspaces/{slug}/members/	200 (returns all members)
GET /api/v1/workspaces/{slug}/members-lite/	404

So the -lite endpoints appear to be Cloud/commercial-only; they are absent from Community Edition (including the latest v1.3.1).

Expected behavior

list_projects and get_workspace_members should work against a self-hosted Community Edition instance.

Suggested fixes (any of)

1. Use the non-lite endpoints (.list() / .get_members()) for these tools. The lite responses are only a trimmed field set; the standard endpoints already return a superset and work everywhere.
2. Fall back to non-lite on 404 — try *-lite, and if the instance returns 404, retry the standard endpoint. Keeps the Cloud optimization while staying CE-compatible.
3. Make lite opt-in via an env flag (e.g. PLANE_USE_LITE_ENDPOINTS=false), defaulting to the widely-available endpoints.

Option 1 or 2 would be the least surprising for self-hosted users.

Impact

Any self-hosted Community Edition deployment. Project and member listing are discovery primitives — when they 404, agents can't enumerate what exists and tend to dead-end before reaching the tools that do work. A workaround exists (pass a known project_id directly to retrieve_project / create_work_item / list_work_items), but it requires the caller to already know the UUIDs the listing tools are supposed to provide.

Happy to test a patch against a live CE v1.3.1 instance.

[SohaibBazaz]

I've been trying to debug the same issue since the past 1 week

You're diagnosis is spot on regarding the "-lite" endpoint. Really want this to be fixed, It's unusable as of now. Were you able to atleast get it running without the "-lite" endpoints?

[DavidPivert]

Hey @SohaibBazaz — glad the diagnosis matched what you were seeing.

Short answer: I did not get the two listing tools themselves working — I worked around them rather than patching the server. Two options depending on what you need:

1. Workaround (no code changes) — what I actually run

Skip list_projects / get_workspace_members entirely and feed known UUIDs directly to the project-scoped tools (retrieve_project, create_work_item, list_work_items, …), which all hit non-lite endpoints and return 200 on CE. Grab the project_id once, either from the Plane web UI URL or a direct call:

curl -H "X-API-Key: $PAT" \
  "$PLANE_BASE_URL/api/v1/workspaces/$SLUG/projects/"

Then hardcode / cache that UUID in your agent config. Not elegant, but it unblocks everything downstream.

2. Actual fix (local source patch)

If you're running from the git tag, swap the lite calls for the non-lite ones. As of v0.2.11 there are three *-lite calls that 404 on CE:

• plane_mcp/tools/projects.py:60 → client.projects.list_lite(...) → client.projects.list(...)
• plane_mcp/tools/workspaces.py:55 → client.workspaces.get_members_lite(...) → client.workspaces.get_members(...)
• plane_mcp/tools/projects.py:344 → client.projects.get_members_lite(...) → client.projects.get_members(...) (the project-scoped get_project_members tool — same 404 for the same reason)

The non-lite responses are a superset of the lite ones and are served by CE, so nothing downstream breaks. That's option 1 from the issue above. I've been meaning to send this as a PR — happy to if a maintainer signals they'd take it.

[SohaibBazaz]

Thanks for the detailed breakdown, can confirm your three call sites match exactly what I found patching a 0.2.11-based build myself.

One thing that might save you the local patch entirely: there's a simpler workaround than #2; pinning to plane-mcp-server==0.2.9 (see #169 ) sidesteps the whole -lite regression, since 0.2.9 predates the switch to lite endpoints. I'm running that pin in production now and list_projects / get_workspace_members both work cleanly against CE with zero source patches

A couple of adjacent things I hit in the same debugging session, separate from the -lite issue but relevant if you're touching this code:

1. The server requires PLANE_OAUTH_PROVIDER_CLIENT_ID/SECRET/BASE_URL to be set even in pure header/API-key auth mode with no OAuth intended — __main__.py calls get_oauth_mcp() unconditionally at startup, so it throws ValueError: client_id is required without them even though they're unused in that mode. Dummy placeholder values work around it, but worth flagging separately since it's unrelated to the -lite bug.

2. The startup log line "Starting HTTP server at URLs: /mcp and /header/mcp" doesn't match the actual mounted routes (/http/api-key/mcp and /http/mcp per the Mount() calls in server.py); cost me some debugging time chasing the logged path before finding the real one in source

Hope this helps!

[DavidPivert]

Thanks @SohaibBazaz — and your 0.2.9 pin is a genuinely useful data point I'd missed. I confirmed it: 0.2.9 calls client.projects.list() / get_members() directly, so it predates the whole regression.

Three follow-ups, one of which is me correcting myself.

1. There's already a PR for this — #173. Neither of us needs to patch locally. @refract99 opened it on 11 July: it adds a lite_or_fallback() helper that tries -lite first and retries the full endpoint on 404, with unit tests and a live CE repro. It's been sitting without maintainer review for two and a half weeks. Worth a 👍 or a confirmation comment from you too — it declares Fixes #172, #170, #169, #126, so this bug has now been reported five or six separate times, which is probably the strongest argument for merging it.

2. My "three call sites" was wrong — there are five. I'd only grepped projects.py and workspaces.py. Across the full v0.2.11 tree:

plane_mcp/tools/cycles.py:67       client.cycles.list_lite(...)            ← list_cycles
plane_mcp/tools/modules.py:60      client.modules.list_lite(...)           ← list_modules
plane_mcp/tools/projects.py:60     client.projects.list_lite(...)
plane_mcp/tools/projects.py:344    client.projects.get_members_lite(...)
plane_mcp/tools/workspaces.py:55   client.workspaces.get_members_lite(...)

So list_cycles and list_modules 404 on CE too — if your patched build only covered the three I listed, those two are still broken. (#173 covers four of the five; I've flagged the missing get_project_members one over there.)

3. Correction on my suggested fix. I recommended simply swapping to the non-lite calls — don't do that. #162, which introduced the lite endpoints, was a deliberate perf fix for large-workspace timeouts. A hard swap re-introduces those. Try-lite-then-fall-back-on-404 is the only approach that fixes CE without regressing Cloud, which is exactly what #173 does.

---

On your two adjacent findings — both look real to me from source, and both deserve their own issues rather than living in this thread, since neither is -lite-related:

• The route logging mismatch is exact. __main__.py:192 logs "Starting HTTP server at URLs: /mcp and /header/mcp", while the actual mounts at lines 167-169 are prefix + "/http/api-key", prefix + "/http", and prefix or "/" (SSE). /header/mcp doesn't exist at all. Clean one-line fix, good first issue.

• The OAuth one I'd reframe before filing, or it'll get chased down the wrong path: it's HTTP-mode only, not "any header/API-key mode". The stdio branch returns at __main__.py:142 (get_stdio_mcp().run(); return) and never reaches get_oauth_mcp() — I run stdio and have never needed those vars. The real bug is narrower and still worth fixing: in HTTP mode, line 148 builds the OAuth app unconditionally, so you can't run only the /http/api-key mount without supplying OAuth credentials you'll never use. Framed that way it's an easy fix (gate the OAuth app construction), and a maintainer won't bounce it as "works for me on stdio".