Permissions and Roles for MCP: Mapping Team Access to Tool Actions

Design role-based access control for MCP usage across your team. This practical guide covers role definitions, permission mapping, approval workflows, and examples for different team roles.

Core Role Definitions

Viewer Role

Viewer Permissions

Purpose: Read-only access for team members who need visibility but shouldn't make changes

Can use: list_tasks, get_task, list_projects, get_project, list_boards, get_board, list_task_comments, get_tracking_status
Cannot use: create_task, update_task, delete_task, add_task_comment, start_time_tracking, stop_time_tracking
Use case: Stakeholders, executives, external consultants

Contributor Role

Contributor Permissions

Purpose: Standard team member access for day-to-day work

Can use: All viewer permissions + create_task, update_task (own tasks), add_task_comment, start_time_tracking, stop_time_tracking
Cannot use: delete_task, update_task (others' tasks without approval), update_project settings
Use case: Individual contributors, developers, designers

Admin Role

Admin Permissions

Purpose: Full access for team leads and managers

Can use: All contributor permissions + delete_task, update_task (any task), update_project, manage boards
Requires approval: Bulk operations, project deletion, workspace settings
Use case: Team leads, project managers, engineering managers

Permission Matrix

Tool Access by Role

Tool	Viewer	Contributor	Admin
list_tasks	✓	✓	✓
get_task	✓	✓	✓
create_task	✗	✓	✓
update_task (own)	✗	✓	✓
update_task (any)	✗	✗	✓
delete_task	✗	✗	✓*
add_task_comment	✗	✓	✓
start_time_tracking	✗	✓	✓

* Admin delete operations should still require confirmation

Approval Workflows

Approval for Sensitive Actions

Even with proper permissions, some actions should require additional approval:

Actions Requiring Approval

Delete operations: Always require confirmation token
Bulk updates: Require preview and approval for >5 items
Status changes to "done": Require confirmation
Project-level changes: Require manager approval
Time tracking on others' tasks: Require explicit permission

Approval Pattern Example

Delete with Approval

"Delete task '[Task ID]' from Corcava: 1. First, get the task details and show me what will be deleted 2. Show me a warning that this action is irreversible 3. Require me to type the exact confirmation token 'DELETE-TASK-2026' 4. Only after I type the token, delete the task 5. If I don't type the token, don't delete anything"

This pattern: Shows preview, requires explicit token, prevents accidental deletion

Role Examples by Team

Engineering Team

Engineering Role Mapping

Junior Developer: Contributor (can create/update own tasks, track time)
Senior Developer: Contributor (same permissions, more experience with workflows)
Tech Lead: Admin (can manage team tasks, update project settings)
Engineering Manager: Admin (full access, manages multiple projects)

Product Team

Product Role Mapping

Product Designer: Contributor (can create design tasks, update status)
Product Manager: Admin (can manage product backlog, prioritize tasks)
Product Owner: Admin (full access to product projects)

Operations Team

Ops Role Mapping

Support Agent: Contributor (can create tickets, update status, add notes)
Ops Engineer: Admin (can manage ops tasks, update runbooks)
Stakeholder: Viewer (read-only access to project status)

Implementing RBAC

Step 1: Define Roles

Role Definition Checklist

List all team roles in your organization
Map each role to Viewer, Contributor, or Admin
Identify any custom permissions needed
Document role responsibilities

Step 2: Assign Permissions

Permission Assignment

Create API keys with appropriate permissions in Corcava
Name keys descriptively (e.g., "John - Contributor - Cursor")
Document which permissions each role has
Set up approval workflows for sensitive actions

Step 3: Enforce Approvals

Approval Enforcement

Create prompt templates that require confirmation
Use confirmation tokens for critical operations
Train team on approval patterns
Monitor write operations for compliance

Best Practices

RBAC Best Practices

Start restrictive: Begin with read-only, add permissions gradually
Least privilege: Give minimum permissions needed for role
Regular reviews: Review permissions quarterly
Document roles: Keep role definitions and permissions documented
Approval for sensitive actions: Always require approval for deletes and bulk operations
Audit logging: Log all permission-related actions

Design Role-Based Access for MCP

Map team roles to MCP permissions and enforce approvals for sensitive actions

Security Guide →Team Rollout