Jira, Linear or ClickUp for coding agents? Mostly the same choice

Search this question and three of the first four results are written by ClickUp, Atlassian and monday.com — each comparing trackers, and each from a company that sells one. They compare boards, pricing tiers and AI assistants. That is a fair comparison for the people on your team. It is mostly the wrong one for the agent.

From where a coding agent sits, Jira, Linear and ClickUp are one design. The tracker is a hosted service. The agent reaches it through an MCP server, signs in with OAuth, and gets the one current state of every issue. The real choice is between that design and the other one, where the tasks live in the repository the agent is already working in.

This page takes the three on their own terms first, from their own documentation, then the other design, and says what each is worse at.

What each one gives an agent

All three now ship a first-party MCP server. That alone settles the question "can my agent read it" — yes, all three.

Read that table for the differences that actually change an agent's day.

ClickUp's limit is the one hard number. Without the Everything AI add-on, the MCP server allows 50 calls in a rolling 24 hours on the Free Forever plan and 300 on Unlimited and above. ClickUp's own docs say the window cannot be reset. Every lookup, every update and every comment is a call. Count your agent sessions before you count the features. The REST API is a separate budget, at 100 calls a minute, but an agent using it needs its own client and a token you manage.

Jira and Linear both turn a ticket into a pull request. In Linear, agents can be assigned issues and do not count as seats; delegate one and a coding session starts through Claude Code or Codex, drafts a PR and adds the diff back to the issue, on the paid plans and against AI credits. In Jira, Claude Agent for Jira takes a work item and opens a GitHub pull request, beside Jira's own coding agent and third-party agents run from automation. If what you want is "file a ticket, get a pull request", either one does it, and nothing in the repository-side design below does.

Jira is the one an organisation already has. The Rovo MCP server reaches Jira, Confluence and Bitbucket through one connection and respects the permissions your admin already set. When the agent's answer has to come from a Confluence page somebody in another department wrote, that matters more than anything on this page.

What all three share

The table hides the part they have in common, and it is the part that decides how an agent actually uses them.

The tracker is not on the branch. A hosted tracker holds one state per issue. Your agent is working on a branch. If it marks a task blocked, writes a note on why an approach failed, or records that the team chose one library over another, that lands in the shared state immediately — whether or not the branch it belongs to ever merges. Abandon the branch and the tracker still says what the branch did. Linear links PRs and commits to issues and can move status from them, which narrows the gap from the other side. It does not make a branch carry its own task state.

Every read is a network call to someone else's service. The agent needs a signed-in session, the service has to be up, and the read costs what the plan says it costs. In a CI job or a sandbox with no credentials, the agent has no tracker at all.

The agent has to decide to call it. This one is not about the three vendors, and we did not measure it against their servers. We measured it against our own search command, in a repository whose CLAUDE.md told the agent to search the recorded decisions before reading code. Agents that searched first: 0 of 10. A tool the agent can call is not a tool the agent calls. There is no reason to expect an MCP tool pointing at Jira to fare better than one pointing at a local file, and the writeup of that experiment is here.

The other design: tasks in the repository

The alternative keeps tasks, and what was decided about them, as files in the git repository. There is a whole category of these now. The Backlog.md comparison lists eight, and kadence, which this site exists for, is one of them.

What changes for an agent is the list above, inverted. The task state is on the branch the agent is on, and merges or disappears with it. Reading it is reading a file: no sign-in, no network, no daily budget. In kadence, one task as an agent reads it is 982 bytes, and a search over the journal takes 26 ms. When three people edit one task on three branches and the branches are merged in every order, the conflicts come to 0 — the reason that design is append-only is here.

What the repository design is worse at

More than the hosted trackers would put in their own comparison of each other, so here it is in full.

• People who do not use git cannot use it. A product manager, a designer, a support lead — they will not open a terminal to file a bug. All three hosted trackers are built for exactly those people.
• No notifications, no mobile app, no roadmap view. There is a board in the terminal and an HTML export. That is not a planning tool for a company.
• One repository at a time. Work that spans five services has no single place to look, which is Jira's whole reason to exist.
• No agent that turns a ticket into a pull request for you. Jira and Linear both do that. None of the repository trackers we have compared does.
• It is young. kadence specifically, as of 30 September 2026: 0 interviews, 0 pilots, no team we know of uses kadence outside its own repository.

How to choose

• The tracker is where non-engineers plan the work. Keep it. Pick between the three on what your team needs, which is what every comparison on the first page of this search already covers well. For the agent, check one thing: on ClickUp, whether the MCP budget fits how many sessions you run in a day.
• You want tickets turned into pull requests. Jira or Linear.
• The question is what an agent on this branch needs to know — what was tried, why a task is blocked, what was decided and what was rejected. That is the part a hosted tracker holds once for every branch, and the part the repository design was built for.

These are not exclusive. The common case is both: the hosted tracker for the plan the company can see, and the repository for the context the agent works from. The mistake is expecting either one to do the other's job.

---