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:
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.
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:
list_projects/ workspace-widelist_work_items404 (list_lite()routes absent on CE)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
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()inapps/api/plane/api/views/issue.pythat 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.