Is the Community Edition a supported target?

Is self-hosted Plane Community Edition (CE) is a supported target for this MCP server? I found a new issue ("pql filters silently no-op on self-hosted CE", documented below). This is a recurring theme — the MCP server assuming an API surface newer than CE provides. IIf this is intentional, as it is today with the Plane mobile application which rejects logging into COmmunity Edition instances, then a stated "no official support for CE" stance would cover:

• makeplane/plane-mcp-server#170 — list_projects / workspace-wide
  list_work_items 404 (list_lite() routes absent on CE)
• makeplane/plane-mcp-server#169 — projects-lite 404 self-hosted
• makeplane/plane-mcp-server#163 — pages tools 404 on CE
• makeplane/plane#8782 — request to add CE OAuth so the MCP HTTP transport
  works against self-hosted (open, no maintainer stance yet)

Precedent

While I would love for this to be a supported target, I recognize this is a substantial engineering effort. If it's not supported, it would eb better to have a stated stance than letting people continue discovering missing features one-by-one and wasting maintainer time

Drawing an edition line for a helper tool has precedent here - the official mobile app does exactly that: docs.plane.so/devices/mobile states it supports "If you are on the Community Edition, upgrade to the Commercial Edition to access mobile app functionality."; a Plane staff member likewise said on the forum "Our mobile app is closed source and only supports cloud and commercial editions." If the MCP server is similarly Cloud/Commercial-oriented, saying so in the README ("works against CE but not officially supported / not tracked") would be entirely reasonable and would give a canonical reply for the issues. IMO it would be useful to also clarify if improvements that target CE are welcome (e.g. "PRs to imrpove CE support <accepted | will be closed as wont-do | etc...>"

PSQL Report

Environment

• plane-mcp-server : v0.2.10 (current main , commit b0fb136 )
• Plane target: self-hosted Community Edition v1.3.1 (open-source
makeplane/plane , AGPL)
• Tools affected: list_work_items (cleanest case), and by the same
mechanism list_archived_work_items

Issue

list_work_items(project_id=..., pql='priority = "urgent"') against a CE instance returns every work item in the project, not just the urgent ones - no error or warning. The same holds for any PQL expression. The result looks like a normal successful response, so an LLM believes it filtered and then reasons over the full, unfiltered set (e.g. "I've launched agents to deeply investigate your top urgent items" launches hundreds of sub-agents 😢 ). Note: A loud 404 would at least be self-correcting.

Details

• Caveat: these details were made with AI-help, please take specifics with a grain of salt

PQL is newer than CE, shipped in Plane v2.6.0 (2026-05-18 changelog: "Filter work items using text-based queries…") and is labeled Pro in the docs. CE has no PQL parser or filter backend. CE therefore ignores the param, per standard DRF behavior. I think this is the chain: server calls (IssueListCreateAPIEndpoint.get() in apps/api/plane/api/views/issue.py that reads only external_id , external_source , and order_by from the query string. Builds the queryset and (never calls filter_queryset()) and it declares no filterset_fields / filterset_class , so the global DjangoFilterBackend never runs. The unrecognized pql param is simply never read — and unknown query params don't error in DRF, they're dropped. Result: the full project-scoped queryset, and a total_count computed over that same unfiltered set.

Server side. In v0.2.10, list_work_items / list_archived_work_items expose pql as their only field/attribute filter — there's no state / priority / label / assignee parameter on the list path. (They do expose external_id / external_source , and those happen to work on CE since CE reads exactly those params — so the tools aren't entirely unfiltered, just missing every attribute filter.) The tools' only PQL error handling is a branch gated on e.status_code == 400 and "pql" in e.response ; since CE returns 200 with a full list rather than a 400 , that branch never fires and nothing surfaces. There's no echo-back or count check that would catch a filter the backend didn't apply.

Start with the README and the affected API entry point, apps/api/plane/api/views/issue.py, then review issues #163, #169, and #170 for the Community Edition compatibility pattern. Confirm which edition targets are supported and document the stance, including how unsupported PQL filtering should be communicated; done means contributors have a canonical support and contribution policy.