[AdamSelene]

Description

Lets project members use the platform MCP server (POST /mcp/platform), governed by the existing per-project READ_MCP permission.

Today platform MCP is effectively admin-only: minting a platform-scoped OAuth token (projectId = null) requires PlatformRole.ADMIN. This PR opens it to members and expresses "who may use MCP" through the project-level READ_MCP permission that already exists, rather than a coarse platform-role gate.

Why it's safe

Platform MCP is cross-project by design, and the per-project enforcement already runs on the platform path — it was simply never reached by a non-admin because the admin gate stopped them first:

• Reach is membership + permission scoped. ap_set_project_context bounds selectable projects to the user's own, and now further to the projects whose role grants READ_MCP.
• Per-project permissions are re-resolved on every tool call (resolvePermissionChecker({ userId, projectId: selectedProjectId })), reading the member's real role in the selected project. Read-on-project-X / write-on-project-Y is enforced independently per project.

Changes

1. Allow members to authorize platform-wide MCP — remove the PlatformRole.ADMIN restriction in the approve controller.
2. New mcpAccess.listMcpAccessibleProjects helper — the single source of truth for MCP reach: all accessible projects for privileged users (and in CE, which has no project RBAC), otherwise the projects whose role grants READ_MCP. Used by both the approve controller and ap_set_project_context.
   • Platform-wide authorization now requires READ_MCP in ≥1 project.
   • Project-scoped authorization now requires READ_MCP on that project (was membership).
3. Harden the permission checker — when the user has no role in the selected project, deny all tools, not just those declaring a permission. Three helper tools (ap_resolve_property_options, ap_resolve_property_chain, ap_validate_step_config) declare no permission but read the selected project's connections; this closes a stale-selection window (a member removed from a project while their 24h Redis project-selection is still live) and hardens the existing project-MCP path.

Behaviour note (EE/Cloud): all default project roles (Admin/Editor/Viewer) carry READ_MCP, so default setups are unaffected. Only a custom role that explicitly strips READ_MCP now loses MCP token minting on that project — which is the intended semantics. CE behaviour is unchanged (RBAC filtering is skipped off-EE, so the helper returns the same accessible-projects set the previous membership check used).

No new endpoints, fields, columns, env vars, or migrations. Frontend consent page already renders the platform-wide flow for any logged-in user — no frontend change.

How was this tested?

npm run test-api on the MCP suites (Node 22):

• CE test/integration/ce/mcp — 256 passed / 3 skipped (14 files). Added: a platform MEMBER can authorize platform-wide (POST /v1/mcp-oauth/approve with no projectId → 200).
• Cloud test/integration/cloud/mcp — 9 passed. Added mcp-access.test.ts (privileged → all projects; member with READ_MCP → included; custom role without READ_MCP → excluded) and a no-role → every-tool-denied case in mcp-rbac.test.ts.
• Existing per-project RBAC coverage (Editor write allowed, Viewer write denied, etc.) still green.

npm run lint-dev — no new errors.

Fixes # (issue)

Breaking change? (required — CI fails if this is left unedited)

• no — reviewed, not breaking
• yes — technical (removed/renamed API field or endpoint, dropped column, new required field, removed/required env var)
• yes — functional (default/limit/behaviour change, new self-hosted setup step)

Security impact? (required — CI fails if this is left unedited)

• no — reviewed, no security impact
• yes — security-sensitive (call out the risk and mitigation in the description above)

🤖 Generated with Claude Code

[github-actions]

Hey — thanks so much for taking the time to open this! 🙏

We've temporarily paused unsolicited pull requests from outside the core team. This isn't about you or the quality of your change — an open PR is a promise from us to review it carefully, and right now the volume (a lot of it AI-generated) means we can't keep that promise for every PR without it becoming unfair to contributors who wait weeks for a reply. So instead of leaving PRs hanging, we close them and point you to a faster path.

Already working with us? If you're an existing customer and we've already discussed this change over Slack, ping us there and we'll add the keep-open label and reopen this PR for review.

You can still build and publish your own piece — just outside this repo, as your own package rather than a PR here. See CONTRIBUTING.md for the full policy. Thanks again for caring about the project. 💜