list_projects fails on self-hosted Plane v1.3.1 because projects-lite endpoint returns 404

[neo-clon]

Summary

plane-mcp-server==0.2.10 appears to call projects-lite when executing list_projects. On a self-hosted Plane v1.3.1 instance, that endpoint does not exist, so list_projects fails with HTTP 404. Pinning the MCP server back to plane-mcp-server==0.2.9 fixes the issue because it uses the regular projects endpoint.

Environment

• Plane MCP server: plane-mcp-server==0.2.10
• Plane SDK dependency from PyPI package: plane-sdk==0.2.19
• Plane self-hosted version: v1.3.1
• Transport: stdio via uvx
• Authentication: API key / PAT configured with PLANE_API_KEY
• Workspace slug: existing workspace slug, redacted here

Observed behavior

Running the MCP tool:

list_projects({"per_page": 10, "order_by": "name"})

eventually fails with:

HTTP 404: Not Found: Page not found.

The authenticated REST API itself is working:

GET /api/v1/users/me/                              -> 200
GET /api/v1/workspaces/<workspace-slug>/projects/  -> 200
GET /api/v1/workspaces/<workspace-slug>/projects-lite/ -> 404

The Plane self-hosted v1.3.1 backend routes expose workspaces/<slug>/projects/, but not workspaces/<slug>/projects-lite/.

Expected behavior

list_projects should work against current self-hosted Plane v1.3.1, either by:

• using /api/v1/workspaces/<slug>/projects/, or
• falling back to /projects/ when /projects-lite/ returns 404, or
• documenting that plane-mcp-server==0.2.10 requires a newer Plane backend than self-hosted v1.3.1.

Workaround

Pinning the MCP server to 0.2.9 works:

{
  "mcpServers": {
    "plane": {
      "command": "uvx",
      "args": ["plane-mcp-server==0.2.9", "stdio"],
      "env": {
        "PLANE_BASE_URL": "https://<self-hosted-plane>",
        "PLANE_API_KEY": "<redacted>",
        "PLANE_WORKSPACE_SLUG": "<workspace-slug>"
      }
    }
  }
}

Direct SDK test with plane-mcp-server==0.2.9 returned the expected project list from /projects/.

Notes

This looks like a regression introduced after 0.2.9, where the projects resource switched from the regular projects endpoint to projects-lite.

[SohaibBazaz]

Confirming the 0.2.9 pin works, I hit this exact issue on self hosted version and independently traced it to the same -lite regression before finding this thread. A couple of additions that might help others:

Full list of affected -lite calls I found (not just list_projects: these all 404 the same way):

• plane_mcp/tools/projects.py → client.projects.list_lite(...) (used by list_projects)
• plane_mcp/tools/workspaces.py → client.workspaces.get_members_lite(...) (used by list_workspace_members or similar)
• plane_mcp/tools/projects.py → client.projects.get_members_lite(...) (used by get_project_members)

All three have working non-lite equivalents (.list(), .get_members()) that return a superset of the lite data and work fine; same pattern already flagged in #188

Also worth noting for anyone pinning to 0.2.9: the tool schema for list_projects in this version doesn't accept workspace_slug as a parameter (it's read from the x-workspace-slug header instead inside the .yaml file), but the docstring's Args: section still mentions it

Thanks for posting the workaround

[CarmeloCampos]

Confirmed on our self-hosted Plane CE instance: list_projects returns HTTP 404: Not Found: Page not found. Pinning plane-mcp-server==0.2.9 is our current workaround. Please keep us posted when the fallback fix is merged and released.