Connect Claude Code to backlog items over MCP
Stefan-Iulian Tesoi · · 7 min read
To connect Claude Code to backlog items it can actually act on, add the backlog's MCP server to the agent's configuration and authorise it once from inside the session. The agent can then list what is ready, read an item with its acceptance criteria, and hand finished work back for review. Nobody pastes a ticket into a prompt.
The mechanics take two minutes. The rest is what comes after: which credential to use, what the agent still cannot do, and how to tell a dead connection from an empty sprint, since those look identical from the chat window.
How do you connect Claude Code to backlog items?
One command registers the server, and one authorisation binds it to you.
claude mcp add --transport http laimonade https://api.laimonade.com/mcp
Then run /mcp inside the session, pick laimonade → Authenticate, and approve in the browser tab that opens. Running /mcp again should show it connected. The server name is a local label, so call it whatever you like.
For a team, commit a .mcp.json at the repository root instead of asking everyone to run the command, and each person authenticates once against the shared entry. The full Claude Code MCP setup, along with Cursor, Codex and any other Streamable HTTP client, is in connect your coding agent. Anthropic's own MCP documentation for Claude Code covers the client side of the same command.
Which credential should you use?
Sign in, unless the caller is a machine. The endpoint accepts two credentials and the choice decides whose name the work is recorded under, which is a governance decision disguised as a configuration detail.
- OAuth sign-in binds the session to a person. A milestone the agent creates is owned by you, and a blocker it reports says whose agent hit it.
- A project API key identifies a project rather than a person. Work lands on the project owner. It is the right answer for CI, cron and scripts, and the wrong one for a developer at a keyboard.
The practical argument for signing in has nothing to do with security theatre. A project API key that is regenerated stops working everywhere it was configured, immediately and by design, so every client anyone set up has to be updated at once. A team that standardised on the key discovers how many clients that is on the afternoon someone rotates it.
What can the agent do once connected?
Fetch work, read it in full, gather context, and give it back. The loop is four steps and the tool surface is organised around them rather than around CRUD on issues.
- Ask what is ready. A numbered menu of the Ready column comes back, with narrower versions for stories, bugs and improvements.
- Load the items you want. "Load 1 and 3" pulls them in full: description, acceptance criteria, estimate, parent epic.
- Get context before editing. Regression notes for the paths about to change, and the project's own rules — CLAUDE.md, AGENTS.md, Cursor rules.
- Hand it back. "Submit 1 for review" moves the item to In Review, asserting the criteria are met, which is why loading it first matters.
Work reaching the agent this way arrives as a work order rather than a ticket: criteria, epic context and the repositories to touch, in one call. Every tool and its permission is listed in the MCP tool reference, which is verified against the server's own registry by a build check, so a tool documented there and missing from the server fails the build rather than misleading you. Why that handover shape is the thing to compare when choosing a tracker at all is the subject of Jira alternatives when an agent reads your backlog.
Menu numbers are session state. They refer to the most recent list the agent asked for, so a number from three turns ago will not resolve. Asking for the menu again is faster than arguing about which list it meant.
Which permissions does it need, and what should you withhold?
Every tool declares one of three, and the client uses it to decide when to stop and ask.
| Permission | What it covers | What the client does |
|---|---|---|
| Read | Returns data, changes nothing | Runs without asking |
| Write | Creates work or moves it forward | Runs without asking |
| Destructive | Undoes a human decision | Asks for confirmation first |
Destructive is narrower than it sounds. It marks tools that take something away from where a person put it, not tools that lose data — archived items stay recoverable. The one to know is delete_milestone, which genuinely removes the milestone and is refused while any epic still points at it.
What matters more is the list of things no permission grants. A connected agent cannot mark work done, cannot add anything to the unattended-implementation queue including its own items, cannot reach a project the connection was not granted, and cannot read your Claude memory, chat history or uploaded files. Those limits are the design rather than a roadmap gap: an agent carries an item as far as review, and a person decides what is done. Why a coding agent integration should stop there is the argument running through what to look for in an agent-native project tracker.
How do you verify it with one real item?
Ask for the sprint, then take one item all the way through. A connection that lists work but cannot submit it is worth finding on a Tuesday, not a Friday.
Ask the agent what is ready this sprint. A numbered list should come back. An empty list is a real answer, not a failure — it means nothing is in the Ready column, and work sitting in Backlog is invisible to an agent on purpose, because Ready is the contract that says an item is specified well enough to act on.
Then load one item, make the change, and submit it. The other half of the confirmation is in the app: the MCP page shows when the credential was last used, which turns "I think it worked" into a timestamp. The connector page is also where the granted projects are changed, with no reconnect needed.
What do you do when the connection drops?
Separate the network from the credential before changing any configuration, because the symptoms are identical and the fixes are not.
| Symptom | Usually means | First move |
|---|---|---|
| Asked to sign in again | Access was revoked, or an API key was rotated | Re-authenticate; check project membership |
| Connected, wrong backlog | Connection granted more than one project | Have the agent call list_projects |
| Numbers do not resolve | Stale menu from an earlier turn | Ask for the menu again |
| Nothing responds at all | Network or endpoint, not auth | Check the health endpoint |
The health endpoint is the quickest discriminator: https://api.laimonade.com/mcp/health needs no authentication and reports the running server version. If it answers, the problem is your credential. If it does not, stop editing MCP server configuration and look at the network. The failures people actually hit are collected in troubleshooting.
Work done while a connection was down is not lost, because it is in the repository. What is missing is the item's side of the story, and that is a manual reconciliation when the connection returns.
Frequently asked questions
Does this work with Cursor as well as Claude Code?
Yes. The same endpoint serves any MCP client with Streamable HTTP transport, and Cursor is one of the clients tested, alongside Claude, Claude Code and Codex. Cursor is configured through .cursor/mcp.json in the repository or globally in settings, and prompts for sign-in on first connect rather than using a slash command.
Can several agents share one connection?
They can share the configuration, and it is usually better that they do not share a credential. A committed .mcp.json gives everyone the same server entry while each person authenticates as themselves, which keeps attribution intact. One API key shared across a team collapses everyone's work onto the project owner and makes rotation an event.
What happens to work done while the connection was down?
The code is safe; the record is not. Commits stay in the repository, so nothing is lost, but items were not moved and evidence was not attached while the connection was out. Reconcile by hand once it is back, and treat a long outage as a reason to audit the board against the repository rather than assuming they still agree.
Are there tools an agent cannot drive at all?
Yes, deliberately. complete_onboarding asks a person three questions about the business through MCP elicitation rather than letting an agent answer them. A client that does not support elicitation has to pass those fields itself, which is why the schema makes them optional — the questions are about what the project is for, and the repository does not know.