Agents Don't Have Hands

Two things landed in the Forge changelog in the first week of August, and most Marketplace vendors read them in the wrong order.

The first: rovo:mcp shipped in EAP. Forge apps can now expose their actions as tools inside Rovo Studio, and RFC-134 flags the next step — exposing those same tools to third-party agents like Claude and Cursor through Atlassian Rovo MCP.

The second: Connect end of support moved from December 2026 to 31 January 2027.

Read together, the vendor-panic version writes itself. Agents are coming for the app layer. The platform is buying itself two extra months to finish the job. Migrate or die.

That reading is backwards.

An agent without tools is a chat window

rovo:mcp is Atlassian conceding something in public that's worth sitting with: the intelligence was never the bottleneck.

A model can decompose a quarter of work into forty tasks in about nine seconds. It can name them well. It can spot the dependency you missed. What it cannot do — on its own, in a way you'd let near production — is write those forty issues into Jira with the correct issue types, the right parent links, the sprint assignment, the field values your project's configuration actually accepts, and do it once rather than three times because the first attempt half-failed.

That's not an intelligence problem. It's a plumbing problem. Idempotency, permission scoping, transactional behaviour, error recovery. The unglamorous parts.

MCP exists because the industry hit this wall at the same time. The scarce resource in agentic anything isn't reasoning — it's a reliable, permission-aware write path. Atlassian shipping rovo:mcp is the platform saying: we have the reasoning, we need your verbs.

Noun apps and verb apps

Here's the line worth drawing through the Marketplace.

Noun apps deliver a thing you look at. A dashboard. A report. A custom view. A chart of sprint burndown. Their value is in rendering — taking data that already exists in Jira and presenting it in a shape Jira doesn't offer natively.

Verb apps deliver a thing that happens. Bulk creation. Template instantiation. Field mutation across a hundred issues. Date sequencing. Their value is in doing — changing the state of the system.

Now ask what an agent does to each.

Noun apps are in genuine trouble, and not because Atlassian is hostile to them. A competent model with read access to your Jira data can generate the view on demand. "Show me which epics are at risk and why" is a question a language model answers well, and it answers it without a pre-built dashboard, tailored to the phrasing of the question. Every static view is a guess about which question you'll ask. Agents make that guess unnecessary.

Verb apps get the opposite treatment. An agent that decides forty issues should exist has to call something to make them exist. That something is a tool. rovo:mcp is the socket, and verb apps are what plugs into it. The more capable agents become at planning, the more calls per day flow through whatever executes the plan.

Put bluntly: anything an agent can render, it will replace. Anything an agent must invoke, it will promote. The test is whether a path exists that goes around you (Fig. 01).

Fig. 01What an agent can route around, and what it can't

Noun — a thing you look at

Agent

Source

Jira data

App

renders a view

Reader

a human reads it

deliverable = text · emittable = yes

Verb — a thing that happens

Agent

Plan

40 issues, decomposed

App

writes them

State

Jira actually changed

deliverable = state change · emittable = no

The chains differ in one property: what the last node is made of. Text the model can emit unaided, so the step in between is optional. A state change it cannot, so the write has to be invoked. That property decides which side of the line an app falls on — not how good the app is.

What this looks like in practice

A tool definition is a contract. Three parts:

A name and description the model reads to decide whether to call you. This is now marketing copy for an audience of one non-human reader, which is a genuinely strange thing to write.
A typed input schema. Not prose. The model fills in fields; your app validates them.
A predictable result — including a legible failure. "Created 38 of 40 issues; 2 rejected because the Team field is required and wasn't supplied" is a good result. A stack trace is not.

The interesting constraint is the third one. Agents retry. A good error message tells the model exactly what to fix, so it fixes it and re-sends — which means the better your failure, the more effectively you get called twice (Fig. 02). Idempotent means the second identical call leaves Jira exactly as the first one left it. Without that, a batch that half-fails and runs again leaves seventy-eight issues where you wanted forty, and reports success both times, because both times it succeeded. Most Marketplace apps have never been called by something that retries without asking permission first. That assumption is about to stop holding.

Fig. 02One retry, two write paths

create(40) → 38 created, 2 rejected — Team is required

retry create(40) → Team supplied, all 40 accepted

Idempotent write

38 in Jira · 0 duplicates

Not idempotent

38 in Jira · 0 duplicates

Both calls returned success. There is no failure here to catch — the damage is the happy path, run twice.

A legible error is what triggers this. The failure told the agent exactly how to fix its payload, so it re-sent all 40 — the behaviour the contract invited. Without idempotency the second call succeeds too, and 38 duplicates land with nothing anywhere reporting an error.

Worth noting what else shipped the same week, because it points the same direction: requestTeamworkGraph() became callable from app frontends, and jira:fullPage / confluence:fullPage were deprecated in favour of a unified global:fullPage (30 September 2026). The platform is consolidating surfaces and opening data access. Both moves make sense if you assume the app of 2027 is called more often than it is clicked.

So why extend the Connect deadline?

Not mercy.

Connect apps can't participate in any of this. Tool exposure, Teamwork Graph access, Rovo integration — these are Forge capabilities. Every vendor still on Connect on 1 February 2027 is a vendor whose functionality is invisible to the agent layer Atlassian just spent a year building.

The extension isn't a reprieve for stragglers. It's the platform making sure the ecosystem it needs actually arrives. Two extra months, framed to avoid overlapping with end-of-year planning cycles — and framed, less explicitly, to get more verbs onto the platform before agents become the default way people touch Jira.

If you're still on Connect, the deadline was never the real deadline. The real one was: be callable before the calling starts.

The checklist

Four questions, in order:

Is your app a verb or a noun? If someone described what it does, would the sentence contain an action or a view? Be honest. "Dashboard with actions in it" is a noun.
If it's a noun, what verb is hiding inside it? Most reporting apps encode real domain logic about what matters. That logic is worth exposing as a tool even when the chart isn't.
Are your write operations idempotent? Can the same call arrive twice without doubling the damage? Most vendors will answer this for the first time while looking at a board with two of everything.
Can you describe your action in two sentences a model would understand? If the description needs a diagram, the tool boundary is drawn wrong.

Where we're pointed

We build a verb. SuperTemplates exists to turn unstructured text into structured Jira issues in bulk — that's the whole product, and it's exactly the shape of thing an agent needs to call and can't do itself. A model that has planned your quarter still needs something to write 250 issues with correct hierarchy and not fall over on issue 180.

So we're watching rovo:mcp closely, and generation-as-a-callable-tool is where we're headed. It isn't shipped. We'll write about it when it is, not before.

The part that could go wrong

One honest caveat, because the argument depends on it.

All of this holds only if Atlassian keeps third-party tool exposure genuinely open. RFC-134 says the right things and the EAP is real. But there's an obvious version of the next two years where first-party actions get privileged placement in the tool registry, where Rovo's own capabilities expand into territory vendors currently occupy, and where "expose your actions as tools" quietly becomes "donate your logic to the assistant."

Platforms have done this before. Worth watching, worth saying out loud, and worth reading the RFC comments rather than the announcement post — that's where vendors are asking the sharp version of this question.

The bet is still worth taking. An agent that can plan everything and build nothing is a very expensive way to produce a to-do list.