Child of PAR-182.
The MCP tools (tesks/src/main/java/io/paradaux/tesks/mcp/TaskMcpTools.java, 19 tools) call the same TaskSystem backend with no role checks — an agent with a workspace MCP key has full read/write/admin power. Once server-side RBAC (sibling issue) lands at the service layer, the MCP tools should inherit it; this issue ensures the MCP key's actor/role is resolved and enforced, and that tool-level affordances match (e.g. mutating tools refuse for read-only keys).
McpAuthFilter already binds the tenant; extend it to resolve the actor's role for the key.Acceptance: an MCP key mapped to a viewer role can read but not mutate; manage-only tools refuse for non-admins.
Verified LIVE (and end-to-end working). Every mutating MCP tool is gated: create→ISSUE_CREATE, update→ISSUE_UPDATE, comment→ISSUE_COMMENT, create/freeze release→SETTINGS_MANAGE; read tools ungated by design. The actor/key role is resolved and bound at tool-execution time via McpRequestContextExtractor + ok(exchange,…) (the PAR-204 fix, commit 114c3b6) — a viewer/under-privileged key is refused on mutations. Confirmed live by issues being created over MCP this session. Acceptance met.
Done on develop (commit
c7d4aa0).ApiKeyService.resolvereturns(tenant, permissions);TenantBearerFilterbinds the key's grants via a newKeyContext;PermissionServicefalls back to it when there's no UI actor. MCP mutating tools (createTask/updateTask/addComment/createRelease/freezeRelease) enforce the matching permission and return a clean denial. New keys default to the contributor role (overload accepts any role slug for the future mint UI); existing keys were backfilled to admin (V19). The static service key / open dev mode keeps full power as a trusted internal credential. Covered byPermissionServiceTest.