Rovo MCP for Jira Capacity Planning: What Managers Can Ask, Change, and Verify

It is Monday morning, and the plan already needs to change.

One person has been pulled into an urgent customer issue. Another has training on Thursday. A priority project needs more attention, but nobody wants to rebuild the weekly capacity plan cell by cell.

This is exactly the kind of job that makes an AI assistant attractive: explain the change in ordinary language, review the proposal, and let the assistant update Jira.

But a confident answer is not the same as a correct allocation. Before a team gives an AI client permission to change the plan, a manager should know what it can see, what it can alter, and how the result will be checked.

The short answer

Rovo MCP can now give compatible AI clients controlled access to Jira's individual capacity plans. Atlassian documents tools for reading allocations, finding non-project work, updating an allocation, and creating or renaming non-project work. The feature is in progressive rollout, and administrators can control its read and write permissions.

Use it as a planning assistant, not as an automatic manager. Start with read-only questions, allow a very small set of approved changes, and verify every write in Jira's Capacity view.

Also keep one boundary clear:

A capacity plan says where you intend people's available time to go. It does not, by itself, prove how many hours were logged, how much work was completed, or whether a project is over budget.

This guide turns Atlassian's current documentation into a practical two-week pilot. The example team and results are fictional. They demonstrate what to test; they are not results from a BacklogBridge customer site.

What changed in Atlassian MCP

On September 24, 2026, Atlassian announced new capacity-planning toolsets for Atlassian MCP v2. The Rovo MCP changelog describes read_capacity_planning and write_capacity_planning access and says the rollout is progressive by tenant.

The current supported-tools reference lists five practical actions:

These tools do not appear automatically for every user in every session. Atlassian says availability depends on the authentication method, required scopes, the permission groups enabled by the organization administrator, and the user's existing app access.

If the tools are missing, do not assume the assistant is broken. First check whether the rollout has reached the site and whether the relevant read or write group is enabled.

What Jira's capacity plan actually represents

Atlassian's individual capacity-planning guide says the native feature is available on Premium and Enterprise plans. It lets teams allocate people to projects, epics, and non-project work in hours, days, or percentages.

That is useful for questions such as:

• Who is fully allocated next week?
• How much of Marta's time is assigned to Project Phoenix?
• Where have we recorded leave or staff training?
• What would the plan look like if we moved 20% of one person's allocation?

The same documentation records an important limitation: the plan currently uses a fixed 40-hour workweek. Custom time-tracking and working-day settings are not reflected in the capacity plan.

For example, allocating someone at 50% describes half of the plan's standard week. It does not prove that the person has 20 real delivery hours available after local holidays, a part-time schedule, meetings, support duty, or unplanned work.

That is why a good pilot tests both the convenience of natural-language planning and the meaning of the numbers being changed.

Keep allocation, actual work, and delivery forecasts separate

Three management questions often get mixed together:

Rovo MCP's capacity tools address the first question. An assistant may combine capacity information with other Jira context, but that does not turn an allocation into a worklog or a budget result.

If the steering meeting needs planned-versus-actual effort, use the Jira original estimate versus time spent guide and show the contributing work items. If the immediate problem is choosing a resource-planning product, use the Jira capacity-planner app checklist.

Before the two-week pilot

Keep the first test deliberately small. One manager, one Jira administrator, three to five people, two pieces of work, and one type of non-project time are enough.

Agree on these points before connecting an AI client:

1. The decision owner. Name the person who will approve or reject changes.
2. The plan boundary. Record the Jira site, capacity plan, people, work, and two-week period in scope.
3. The client. Record which compatible AI client is connected and which account is signing in.
4. The starting permissions. Begin with capacity read access. Keep write access blocked until the read results have been checked.
5. The test data. Use fictional or non-sensitive work where possible. Do not begin with payroll-sensitive absence data or a critical portfolio plan.
6. The success rule. Decide what would make the pilot useful: fewer manual edits, accurate answers, reproducible results, and no unexplained changes.
7. The rollback. Save the starting allocations so every test write can be reversed.

Atlassian's getting-started guide recommends OAuth 2.1 for ordinary interactive use. Authentication is only one control, though. The organization still needs appropriate user access and MCP permission groups.

Week one: keep it read-only

The first week should answer a simple question: can another manager reproduce what the assistant says by opening Jira?

Day 1: confirm the boundary

Ask for a narrow view:

Show the capacity allocations for Alex, Priya, and Mo in the Phoenix
capacity plan for September 28 through October 9. Include the person,
work item or project, period, and allocation value. Do not make changes.

Check the returned people, dates, work, and units against the Capacity view. A polished summary with the wrong week is still wrong.

Day 2: inspect non-project work

Ask the assistant to find recorded leave, training, or other non-project work for the same people and period.

Verify that the assistant has not treated an empty row as available time or invented a reason for the absence. If a record says only “Unavailable,” the answer should not quietly rename it “Annual leave.”

Day 3: ask for observations, not decisions

An assistant can make the grid easier to scan:

Using only the returned capacity-plan data, identify allocations that
exceed 100% and people with unallocated capacity. Show the arithmetic.
Do not recommend staffing changes and do not update the plan.

Recalculate at least one result manually. The point is to test whether the answer is inspectable, not whether it sounds efficient.

Day 4: test a second viewer

Have another appropriately authorized manager run the same questions. If the answers differ, check user permissions, site selection, plan scope, and dates before blaming the model.

Different answers can be correct when two people are allowed to see different information. They can still be unsuitable for a shared management decision.

Day 5: write down the gaps

Record every result that needed correction or clarification:

• Wrong person, period, plan, or work item
• Missing non-project work
• Allocation unit misunderstood
• Answer based on information the reviewer could not reproduce
• Confident conclusion that went beyond the returned data

Do not enable writes because most answers looked right. Enable them only when the agreed read tests pass.

Week two: allow a few controlled changes

If week one is reliable, the administrator can enable only the required capacity write group for the pilot users. Atlassian's MCP permission guidance separates read and write controls and allows administrators to manage toolsets by intent.

Day 6: request a proposal only

Start with language that forbids execution:

Propose moving 20% of Alex's Phoenix allocation in the week of
October 5 to Priya. Show the current values and proposed values.
Do not change the capacity plan.

The reviewer should be able to see four things before approving anything: person, work, period, and new value.

Day 7: make one approved change

Once the proposal is correct, authorize only that change. Immediately open Jira and check the relevant people, work, dates, and values.

Do not treat a successful assistant message as proof that the plan changed correctly. The Capacity view is the operational record the manager needs to inspect.

Day 8: add one non-project item

Test a low-risk item such as two hours of training for a fictional user. Confirm its name, dates, amount, and effect on the person's visible allocation.

Avoid a broad instruction such as “fix everyone's availability.” It hides too many decisions inside one request.

Day 9: prove that the guardrail works

Ask the administrator to block the capacity write group for the test user, then repeat a harmless change request. A useful control should produce a clear refusal rather than silently applying the update.

Atlassian says MCP settings can control read, write, and search access. Its security settings guide also advises least privilege, review of high-impact changes, and monitoring audit logs for unusual activity.

Day 10: reverse the test and make a decision

Return the plan to its recorded starting state. Ask the second manager to repeat one read check. Then score the pilot on accuracy, safety, usefulness, reproducibility, and time saved.

Download the two-week Rovo MCP capacity pilot worksheet to record the prompts, permissions, expected results, Jira checks, rollback, and decision.

A fictional example: the plan looks better, but is it right?

Imagine a manager begins with this simplified plan for one week:

An urgent support issue needs another day from Alex. The manager asks the assistant to propose moving 20% of Alex's Phoenix allocation to Priya.

The proposed plan is:

The arithmetic works. That still leaves management questions:

• Does Priya have the right skills and context for the transferred work?
• Is the 40-hour standard week a reasonable representation for these people?
• Does training remain protected, or is it the next allocation to be removed?
• Has the delivery forecast changed even though the allocation total still looks balanced?
• Who approved the trade-off?

This is why the assistant should prepare the change, not own the staffing decision.

Every person, percentage, project, and result in this example is invented. It is a teaching fixture, not output captured from Atlassian MCP.

How to score the pilot

A simple scorecard is more useful than “the demo felt good.” Rate each area from 1 to 5 and keep the evidence beside the score.

Expand only if the team can explain why it trusts the result. A fast workflow that requires a private spreadsheet to verify has not removed much work.

Common mistakes to avoid

Giving write access on day one

Read accuracy should be established before the assistant can change the shared plan.

Asking the assistant to “balance the team”

That request hides priorities, skills, deadlines, and human commitments. Ask for a visible proposal under named constraints.

Treating allocation as actual effort

A 100% allocation does not prove 40 hours were logged or that the planned work was completed. Use worklogs and delivery reports for those questions.

Testing only as an administrator

The result should work for the manager who will use it, with the permissions that person normally has.

Skipping the rollback

If the team cannot restore the starting state, the pilot was not controlled.

Questions managers usually ask

Can Rovo MCP change a Jira capacity allocation?

Atlassian's current tool reference documents an action for updating capacity-plan allocations. The relevant write permission, scopes, user access, client, and tenant rollout still have to allow it.

Can we keep the pilot read-only?

Yes. Organization administrators can manage the capacity read and write groups separately. Begin with read access and enable only the write capability required for the controlled test.

Does it work on every Jira plan?

No universal availability should be assumed. Atlassian documents individual capacity planning for Premium and Enterprise, while the MCP tool rollout is progressive by tenant.

Does the capacity plan respect our custom working week?

Atlassian currently says the native individual capacity plan uses a fixed 40-hour week and does not reflect custom time-tracking or working-day settings. Check the latest documentation before relying on that behavior in a later rollout.

Does a balanced capacity plan mean the project is on track?

No. It shows planned allocation under the plan's rules. Delivery status also needs scope, completed work, blockers, estimates, remaining effort, and actual time where those measures are used.

Is OAuth enough to make the workflow safe?

OAuth is an important authorization layer, not the complete operating model. Keep least-privilege permissions, narrow prompts, human confirmation, Jira verification, audit review, and a rollback path.

Let the assistant prepare the change, not make the decision

The new Rovo MCP capacity tools can remove tedious navigation and make allocation changes easier to describe. The value is real when a manager can see the starting point, review the proposed change, approve a narrow action, and verify the result.

That is a better standard than “the assistant said it worked.”

For the broader connection between AI clients and Jira, read the Jira MCP Server introduction. For a buyer-focused view of native and Marketplace planning options, use the capacity-planner app checklist. If the real question is planned versus recorded effort, continue with the Jira reporting guide and evaluate TimePillar against that separate reporting need.