Jira's MCP Judges Agents by Final State. The Record Still Has No Cause Field.

Three things landed on the roster inside 36 hours this week, and together they say where the agent record is going. Ryan Lohan's write-up of the Jira MCP redesign, Dave Meyer's Jira autumn release, and Ben Hylak's one-liner about headless MCPs. The record gained the agent's identity and the agent's outcome. The field that would have held the agent's reason was described as one no agent needs.

The short version

Ryan Lohan's "Jira's depth, on demand" (Inside Atlassian, October 28, 2026) is the most specific MCP tool-design post on the roster this month: Jira's REST API documents roughly 725 operations, v1 shipped 15 tools mapped onto endpoints, and v2 is 52 tools shaped like jobs over more than 100 APIs, six always loaded and 46 deferred behind executeRead, executeWrite, and executeDestructive. More than 15M calls every weekday, nearly 2M monthly users, failed tool calls from 0.20 to 0.09 per run, and "we judge outcomes by final Jira state, not by what the agent says." Same day, Dave Meyer's autumn release gives every agent its own identity on the board, in list, and on the work item. So the record has who, and the score is what. The claim to argue with is in Lohan's v1 critique: the transition tool accepted the REST API's historyMetadata "with nested actor, generator, and cause records that no agent needs." Cause is why. Amplitude put an optional Tool Rationale on every tool and agents filled it in about three quarters of the time unprompted. The field note: an optional reason on every write tool, stored on the history entry, is the smallest change that makes the identity on the board worth clicking, and it is the one the system-of-record argument turns on.

What Atlassian built

Lohan's post is worth reading in full for the debate it records. Jira's public REST API documents roughly 725 operations. The easy v2 path was one tool per endpoint, automated from the spec. The team argued for the opposite: start from the job, not the API, because Jira operations rarely work alone, more tools means more wrong picks, and most people use a small slice of Jira.

The result is 52 Jira tools that between them call more than 100 APIs, grouped by intent: 27 read, 15 write, one search, three delete, and six manage, with delete and manage off by default behind their own scopes. Six tools load up front. The other 46 are found through discover and run through executeRead, executeWrite, or executeDestructive, so the risk tier of each call is explicit. v1 had loaded all 32 definitions, about 60 KB of schema, before the user typed anything.

The design rules are the part most teams will copy. Enums instead of tool sprawl, so one manageJiraSprint takes create, addIssues, start, update, or close. Lookups by name, so "the active sprint on the Payments board" resolves without a sprint id. Descriptions that say when to use a tool and which neighbour to use instead. Errors that name the field at fault and carry a repairHint, so the agent corrects itself instead of looping. And governance as part of the answer: closing an issue is still two calls, list the transitions valid for this issue and this user right now, then transition with the fields the workflow requires, one more round trip than a simple tracker in exchange for the validators still applying.

Then the numbers. More than 15M calls every weekday. Nearly 2M monthly active users, up 8x since March 1. On an internal October evaluation of 84 cases, v2 completed 17 tasks v1 had no tool for, passed 57 of the 62 both could attempt against v1's 54, and cut failed tool calls from 0.20 to 0.09 per run. Loading the full catalog up front used roughly 2.2 times the cumulative input tokens of the curated, deferred approach. And the sentence I would frame: "We judge outcomes by final Jira state, not by what the agent says. If it reports creating an issue and none exists, that's clearly a failure."

The same day, the board got names

Dave Meyer's autumn release post, also October 28, is the other half. Agents are doing real work in Jira, and the release makes them something you can see. AMP, Atlassian's Agentic Multiplayer Protocol, gives every agent its own identity, and it shows up where the work is: on the board, in list, on the work item. An agent usage dashboard connects agent activity across Rovo, coding tools, and third-party agents to cycle time, throughput, and shipped work.

Put the two posts together. The record now carries who acted (the agent's identity), what the outcome was (final state, which is also how the MCP is scored), and when. That is the shape Which Door Keeps the Receipt predicted: final state, timestamp, and acting identity get written back reliably because the record cannot function without them. Reasoning, rejected alternatives, retries, and reversals usually do not.

The field that was called unnecessary

In the v1 critique, Lohan lists what the first tools got wrong. One item: transitionJiraIssue "accepted the REST API's full historyMetadata object, with nested actor, generator, and cause records that no agent needs." The v2 example of closing an issue carries a transition id and a resolution. Adding a comment is a separate tool.

Two thirds of that sentence is now right for a reason the post itself supplies. Actor and generator are the agent's identity, and AMP puts that on the record for every action. The third record is cause. Cause is the field that says why.

Attack the claim, not the team; the rest of the post is the design a reason field needs to live in. But the evidence that agents will use the field is already published. Agents Don't Answer Interviews. Amplitude's Left a Note. reads Chanaka Perera's October 6 post on consolidating Amplitude's MCP server: every tool carries an optional Tool Rationale parameter asking why the agent is calling it, and agents filled it in about three quarters of the time without being told to. Amplitude used the rationales to explain a funnel in which 18,703 users queried data, 20% rendered a chart, and under 5% saved one. The rationales showed agents trying to save and failing to finish a three-step chain, so the chain became one call and 16 chart tools became four. Nobody interviewed an agent. The agents left notes.

The Jira version of a missing cause is a closed ticket with an agent's avatar on it and no way to learn why. I know the shape because I counted it in my own repository: Who Writes Your Agent's Rules? I Counted the Commits. found 51 commits to the agent's rule files since March 30, at least 21 with an agent co-author line and 30 I could not attribute. The board with AMP on it is the identity half of that fix. The cause field is the other half, and it is the half that lets a PM read the ticket history on Friday and know whether the agent closed the issue because the resolution was set or because it matched a transition name.

The one-field change

An optional reason on every write tool, stored on the history entry of the record it changed. Not a comment, which is a separate object the agent has to decide to create, and not a log line in the agent's own trace, which is the context the interface keeps and never writes back. On the entry, next to who, what, and when.

Atlassian already has the mechanism for the governance half: a transition reads the workflow and applies the validators. The reason field is the same idea pointed at the reader. Lohan's own description of how the team improves the server is the argument: they use the MCP to drive their own work, and where the tools are clumsy it shows up in their own sessions as extra lookups and retries. A reason on every write is that signal written into the product instead of the trace.

Then the test from Which Door Keeps the Receipt: a reversal made in one interface is visible, with its cause, from another. An agent reopens PROJ-1234 through the MCP; the person on the board sees who reopened it, and why.

Ben Hylak's line this week, posted by Simon Willison on October 29: every product he uses should just be a headless MCP that feeds into an agent, except his own product, where customers love the UI. The joke is accurate about every product team's position, and Benioff Said AI Replaces the UI. Then He Named the Product. argued the way out: software survives as record and governed action, not as the thing you look at. The interface that keeps the most unwritten context becomes the system of record by accumulation. The product that wins the headless argument is the one whose record holds the why.

Under Enterprise AI Agents the claim is that what matters is how many deployed agents still complete production work after ninety days, and what each outcome costs. Judging by final state is the right scoreboard for the first half. The cause field is how the team finds out why the ones that stopped, stopped.

This week: if you ship an MCP server, add an optional reason parameter to every write tool and store it on the history entry; count the fill rate after a week against Amplitude's three quarters. If you buy agent tooling, open the last ten records an agent changed and try to answer why for each one from the record alone. The count you cannot answer is the field note.

Related answer: Should an MCP write tool take a reason field?

Sources: Ryan Lohan, "Jira's depth, on demand: designing an MCP server around jobs, not endpoints," Inside Atlassian, October 28, 2026, read in full. Dave Meyer, "Jira's autumn 2026 release: a faster board and better work item, agents you can actually see, and consistency without the admin tax," Inside Atlassian, October 28, 2026, read in full. Simon Willison, "A quote from Ben Hylak," October 29, 2026. Chanaka Perera's Amplitude post and its figures are as read in Agents Don't Answer Interviews. Amplitude's Left a Note.; the commit count is in Who Writes Your Agent's Rules? I Counted the Commits..