Assessment: Plane MCP server
Plane is open-source project management, and their MCP server lets an agent work a workspace — projects, work items, cycles, comments — including deleting them. What sets it apart isn't that it annotates its tools; plenty do. It's that it makes the annotations impossible to get wrong, with tests that fail the build if the safety metadata ever stops matching what the tools actually do. This is a generous assessment; the server earns it.
1 — Tool annotations · derived and checked — the standout
Plane's tools bundle several actions each (a work-item tool that can get, list, search, create, update and delete). Rather than hand-write a hint per tool and hope it stays true, the server derives each tool's readOnlyHint and destructiveHint from its actions — and then a conformance test asserts the derivation: readOnlyHint is true only if every action reads, destructiveHint true if any action is destructive. The metadata cannot drift from the behaviour, because a test checks they still agree on every build.
2 — Destructive-operation gating · passes, and enforced by CI
Every delete action is marked destructive=True — and this isn't left to discipline. A test, test_delete_actions_are_marked_destructive, fails the build if any action whose name starts with "delete" isn't marked destructive. A companion test does the same for reads. The guarantee isn't "we remembered"; it's "CI won't let us forget", which is the only kind of guarantee that survives a growing team.
3 — Path handling · not applicable
API-backed; no filesystem surface to traverse.
4 — Query and injection safety · low surface, handled
Filtering goes through Plane's own query language passed as structured parameters to the API, not raw SQL exposed to the model. No place for a smuggled second statement.
5 — Untrusted content · passes
Tools return the workspace's own project and work-item data over authenticated OAuth, not open-web content. There's a dedicated test_oauth_security.py guarding that boundary — a sign the team treats the auth surface as something to prove, not assume.
6 — Access model · passes
OAuth with a proper provider, secrets pulled from AWS Secrets rather than the environment, stateless HTTP, and a governance layer that reads who owns a resource and whether the workspace's plan even permits an action before attempting it. The agent operates strictly within the authenticated user's workspace and plan.
7 — Tests and CI · passes
Twenty test files, including OAuth security, stateless-HTTP behaviour, argument validation, docs, integration calls, and the conformance suite above. A build-branch workflow runs them. The safety properties are claims with tests behind them.
8 — Claim versus reality · machine-checked
The strongest pass on the list, for the same reason as the annotations: the consistency between what a tool declares and what its actions do is not asserted, it's tested on every build. The docs and the schema are checked to agree (test_action_literal_matches_the_declaration). Reality can't quietly diverge from the claim.
Tier two — the hardening
Plane does better on tier two than most, thanks to its governance layer — and still hasn't reached all of it.
Confirmation (8) · not yet. Delete actions are marked destructive and the marking is CI-enforced, but the server doesn't require an explicit confirmation before acting — the same elicitation gap almost every server has.
Re-validation & depth (10, 11) · a genuine strength. The governance layer checks resource ownership and whether the workspace's plan even permits an action before attempting it — an action-time check and a real second layer beyond authentication, which most servers lack entirely.
Approval-replay and blast radius (9, 12) · open. No consume-on-use approval flow, and bulk and rate limits rest on the Plane API rather than the server — the same frontier items as its peers.
One thing a full review would discuss
Not a fault — a design trade-off worth a conversation. Because hints are per-tool and tools bundle actions, a tool that can both read and delete gets destructiveHint = true for the whole tool (correctly, and conservatively). A host that gates strictly on destructiveHint therefore blocks that tool's reads too, not just its delete. That's the cost of the fewer-richer-tools design, against the alternative of many narrow single-action tools. Both are defensible; which is right depends on how Plane's clients actually gate. That conversation — not a bug list — is what the deeper engagement would be.
Verdict
Sound, and unusually disciplined about staying that way. Most servers that are safe today are one careless merge from not being; Plane wired the safety properties into CI so a merge can't quietly break them. Reviewed, sound, and here's exactly how I know — with one design question flagged for discussion rather than fix.
Want the same for your server?
Read the whole thing, a test behind every finding, a document you can forward. How the service works · lesliekadenge@gmail.com.
Every claim above is checkable against the public repository at github.com/makeplane/plane-mcp-server. Offered in good faith; the server is named only for what it does well, and the one open question is flagged as a design choice, not a defect.