What is MCP, and why does it matter for your backlog?
Stefan-Iulian Tesoi · · 6 min read
The Model Context Protocol is an open standard that lets an AI agent call tools on an external system through a defined interface. For a backlog it means an agent can fetch its next work order, read the acceptance criteria, and submit evidence back — without anyone copying text between windows.
That sounds like plumbing. It is, and the plumbing is what changes the ceiling on how many agents one person can usefully run.
What is the Model Context Protocol?
MCP is a specification for how an AI agent discovers and calls tools that somebody else built. A server declares what it can do — here are my tools, here are their arguments, here is what they return — and any client that speaks the protocol can use them without either side knowing about the other in advance.
Claude Code and Cursor both speak it. So the useful mental model is not "an integration with our tracker" but "a port our tracker exposes", which any current or future agent can plug into.
That framing matters when you go looking for an MCP server for project management, because most of what is marketed that way is a wrapper over an existing tracker's REST API. Wrapping a read API in MCP makes a backlog legible to an agent. It does not make the items executable, and legibility was never the shortage.
The specification itself is worth ten minutes if you are deciding whether to build against it. It is short, and being short is most of the point.
How does an MCP server differ from an ordinary API?
Functionally, not much. Practically, in three ways that matter for who can use it.
| REST API | MCP server | |
|---|---|---|
| Who reads the docs | A developer, once | The agent, every session |
| Discovery | Out of band, in a portal | In band, from the server |
| Auth | Keys a developer wires up | One authorisation, then the client holds it |
| Failure | A 400 in a log | A tool result the agent can reason about |
The row that does the work is the first. An ordinary API needs somebody to read its documentation and write code against it. An MCP server describes itself to the agent at connection time, so the integration is the connection — there is no glue to write, and no glue to maintain when a tool changes shape.
What does a backlog expose over MCP?
Roughly four families of tool, and the split between them is where the design decisions live:
- Read the work. What is ready, what is in this sprint, what does item 3 actually say.
- Read the context. The epic this rolls up to, the repository conventions, what has been tried before.
- Submit work. Move an item to review with evidence: commands run, exit codes, files changed.
- File new work. A bug found while building something else, with provenance back to the item that surfaced it.
Notice what is not on that list: closing an item. Laimonade's MCP surface can move work to review and cannot mark it done, because an agent that closes its own story removes the only independent check in the chain. The MCP tool reference is the full list, and connecting your coding agent is the setup.
Copy-paste versus a tool call: what actually changes?
Pasting a ticket into a prompt works fine for one agent. It stops working at about two, and the reason is not typing speed.
Three things break. The paste is lossy — whoever copies takes the description and leaves the acceptance criteria, because the description is what looks like the instruction. It is stale the moment it lands, so an item edited after the paste is worked from a version nobody can reconstruct. And the return trip has no home: the agent finishes, reports into a chat window, and somebody transcribes a summary into the tracker, which is where the evidence quietly stops being evidence.
To connect a coding agent to a backlog is therefore to remove a person from the middle of a mechanical step, and only from there. A tool call fixes all three losses above. What remains for the person is the two ends — deciding what matters, and judging what came back — which is the correct division and roughly the argument in what an AI product owner actually does.
Permissions, scope, and what an agent should not be able to do
A backlog MCP server is a write surface on the system of record for what your team is building. Three things are worth settling before you connect one:
- Scope the tools, not just the token. A read-only connection is easy to reason about and nearly useless — the point is submitting work. So the question is which writes: moving to review, yes; deleting items, no; closing items, no.
- Keep destructive operations out entirely. Not permission-gated, absent. A tool that cannot be called cannot be called by mistake.
- Know what the agent can see. An MCP server that returns the whole backlog to any connected client has a different blast radius from one scoped to the current sprint. Ours is scoped to the sprint's ready column, which is also the only part an agent needs.
The general principle is that the protocol gives you an interface, not a policy. MCP will happily expose a tool that wipes your roadmap; deciding not to build that tool is your job.
What it does not solve
Worth being clear about, because the protocol gets credited with more than it does.
MCP moves work orders and evidence around. It has no opinion on whether the work order was any good. An unexecutable item delivered over a beautifully designed protocol is still an unexecutable item, and the agent will still guess at the repository nobody named.
So the sequence matters. A team whose backlog items are not executable gets very little from connecting an agent to them, because the bottleneck is upstream of the transport. The four defects in a backlog an agent can actually read all survive the switch from copy-paste to tool call untouched — they are properties of the text, and MCP carries text faithfully.
The honest order is: make items executable, then remove the typing. Doing it the other way round automates the handover of work nobody can act on.
Frequently asked questions
Which agents support MCP?
Claude Code and Cursor both do, and the list has been growing since the specification was published. That is the practical argument for building against the protocol rather than writing a bespoke integration per tool: the integration you write once keeps working as the client landscape changes, because the contract is with the protocol rather than with a vendor.
Does MCP give an agent access to my whole codebase?
No — MCP is how the agent talks to other systems, not how it reads your files. Your coding agent already has whatever filesystem access you gave it when you started it in a repository. A backlog MCP server adds the ability to fetch work orders and submit evidence, and nothing about your code.
Can an agent close its own tickets over MCP?
Not through ours, and that is a design decision rather than a missing feature. Finished work moves to review carrying its evidence and stops there for a person to close. The whole value of the verification step is that something other than the author does the checking, so exposing a "mark done" tool would remove the reason the rest exists.
What happens when the connection drops?
Work continues and the record does not, which is the failure worth planning for. An agent mid-task keeps building; what it cannot do is submit. In practice that means the evidence has to be filed on the first call after the connection returns, and a team that treats a dropped connector as permission to skip the record will find the work invisible to every report a week later.
Is this worth it for a solo developer?
At one agent, honestly, no — pasting a ticket is faster than configuring anything. It starts paying at two, and the reason is the return trip rather than the outbound one: transcribing what two agents did into a tracker by hand is the part that stops happening on a busy day.