Issue Summary

Customers using third-party worklog management addons need the ability to disable specific Rovo MCP tools at the organization or site level without affecting user-level permissions.

Background

Rovo can create, edit, and delete native Jira worklogs via the Jira API. Customers who use custom worklog addons that operate as an extension of native Jira worklogs (not a replacement) face a data integrity risk: Rovo bypasses the addon's data layer entirely, resulting in data inconsistencies and polluted worklog data.

Restricting worklog permissions at the user level is not a viable workaround because these addons call the Jira API on behalf of the logged-in user and depend on those permissions to function. Revoking worklog permissions from users would break the addon's functionality.

Current State

Rovo's permission model operates at the intent-group level (Read, Write, Search), not at the individual tool level. Disabling the Write group for Jira would prevent worklog actions but also block all other Jira write operations (create issue, edit issue, add comment, transition, etc.).

Requested Enhancement

Provide admin controls in Atlassian Administration > Rovo settings to selectively disable individual MCP tools (e.g., addWorklogToJiraIssue, updateWorklog, deleteWorklog) while keeping the rest of the Write permission group active.

This would allow organizations to:

• Protect addon data integrity without breaking addon functionality
• Maintain full Rovo write capabilities for non-worklog operations
• Control Rovo's behavior independently of user-level permissions