Most AI coding agents in 2026 ship code fine. They write tickets, fix bugs, open PRs, even argue back when you’re wrong. The thing they’re consistently bad at is knowing what sprint you’re in.
The agent doesn’t know which sprint is active. Doesn’t know what the goal is. Doesn’t know which tickets are in scope, which are stretch, which are blocked. Doesn’t know whose ticket it just closed. So when the human asks “what should I work on next?” the agent answers from the current branch, the open files, and whatever it can grep — never from the actual plan.
This is the gap MCP fixes. And it’s why we relaunched mcp.sprintflint.com as a public endpoint. This post is the practitioner’s version: what MCP actually is, what changes when your sprint state is reachable from inside the editor, and the four ways teams misuse the integration in the first two weeks.
What is MCP, in one paragraph
The Model Context Protocol is a standard for tool-using AI assistants to talk to external systems. The agent connects to an MCP server, the server advertises a list of tools (functions the agent can call) and resources (data the agent can read), and the agent uses them as part of its normal workflow. It’s the missing layer between “the agent has access to a shell” and “the agent has access to your sprint planning database.” MCP is to AI assistants what LSP is to editors — one protocol, every implementation.
What changes when sprint state is in the editor
Before MCP: the engineer pastes the ticket description into Claude. The agent reads it, generates a plan, writes code, hands back. The engineer copies the result into the ticket comment. Two manual context bridges, both of which leak.
After MCP: the agent reads the ticket directly. Knows the acceptance criteria. Knows the linked PRs. Knows what was discussed in the comments yesterday. When it finishes, it posts a comment to the ticket with a status update. When the engineer asks “what’s blocking the sprint?”, the agent queries the actual board, not the engineer’s memory of the standup.
Concretely, after one week of usage, the patterns we’ve seen settle into:
- Pull-mode planning. The engineer starts a session with “what’s next on my plate?” The agent calls
list_my_open_tickets, picks the highest-priority one not blocked, asks the human to confirm, and starts work. No tab-switching to the board. - Auto-comment on PR open. When the agent opens a PR, it posts a comment to the SprintFlint ticket linking the PR. Closes the loop without engineer effort.
- Sprint-aware code review. When the agent reviews a PR, it pulls the linked ticket, reads the acceptance criteria, and flags PRs that don’t meet them — instead of only commenting on style.
- Standup pre-write. Before the human’s standup, the agent pulls “what tickets did I close yesterday, what am I working on today, what’s blocked?” and writes the standup message. The human edits two words and posts.
None of these require code changes. They require the agent to be able to see the sprint state.
Why this is a relaunch
We had MCP in v1.1, removed it in v1.2 in favour of an open-source agent skills approach, and watched the MCP spec stabilise around the 2025-06-18 protocol revision. It’s now the de-facto standard. Cursor, Claude Code, Zed and Claude Desktop all speak it. So we’re back, with a thinner implementation: a single Streamable HTTP endpoint at mcp.sprintflint.com, bearer token auth (the same token as the REST API), and a tools catalogue mapped 1:1 onto the resource model.
Setup, in 30 seconds
The Claude Desktop config:
{
"mcpServers": {
"sprintflint": {
"url": "https://mcp.sprintflint.com",
"headers": { "Authorization": "Bearer YOUR_TOKEN" }
}
}
}
Drop into ~/Library/Application Support/Claude/claude_desktop_config.json (or the equivalent on your OS), restart Claude Desktop, the SprintFlint tools appear in the tools menu. Cursor and Claude Code use almost identical config — full per-editor instructions on the /integrations page.
What the tools are
We chose to keep the surface narrow on relaunch. Six tools, mapped to the actions a developer actually takes during a sprint:
| Tool | What it does |
|---|---|
list_projects |
List projects in your organisation |
list_active_sprints |
List active sprints across projects |
list_tickets |
List tickets, filterable by sprint, status, owner |
get_ticket |
Read a ticket including comments |
create_ticket |
File a new ticket into a sprint |
comment_on_ticket |
Post a comment to a ticket |
The two we deliberately did not ship on day one: delete_ticket and move_ticket_between_sprints. Both are reversible in the UI, neither maps cleanly onto a single agent intent, and both have the failure mode where a hallucinated argument quietly breaks sprint planning. The cost of “the agent decided to move the wrong ticket out of the sprint” is much higher than the cost of “the engineer clicks the move button themselves”, so the agent doesn’t get those tools yet. We’ll revisit when patterns settle.
Four ways teams misuse it in the first two weeks
We’ve watched this happen enough times to call it.
1. Letting the agent file every thought as a ticket. The agent’s default disposition is to produce artefacts. Without a guardrail, it will create a ticket every time the human says “oh by the way, the loading state on the dashboard is weird”. The sprint backlog becomes a dumping ground in three days. Fix: tell the agent in its system prompt that ticket creation is a deliberate action, not a default. Confirm before filing.
2. Auto-closing tickets on PR merge. Tempting. Sometimes wrong. A merged PR doesn’t always close the ticket — it might be one of three PRs against the same ticket, or it might pass review without addressing the actual acceptance criteria. Fix: agent posts a “this PR closes ticket X, please confirm” comment instead. Human closes the ticket.
3. Treating the agent as a stand-in for the PM. The agent can read the sprint, but it doesn’t know the strategic context. “Should we add this to next sprint?” is a PM question, not a tool-call question. Fix: the agent surfaces tickets, the human prioritises.
4. Token sprawl. Bearer tokens have full org access. If your agent connection is shared across machines, your token is shared across machines. Fix: one token per developer, named, revocable. SprintFlint’s account settings page lists all active tokens with last-used time so you can spot orphans.
Where this is going
The relaunched MCP server is the foundation. The next layer is server-driven prompts and resources — the MCP spec includes both, and they let the server tell the agent things like “here’s the standard format for a sprint goal” or “here’s the team’s definition of done” without the developer pasting them into every session. We’ll add those over the coming sprints, behind an opt-in flag while we figure out which prompts actually move the needle. Until then, the tools surface above is enough to close 80% of the context gap that motivated v1.7.
Try it
- Generate a token from your account settings on sprintflint.com
- Drop the JSON config into your editor
- Open a session and ask: “what’s the active sprint and what’s still open?”
If your editor doesn’t speak MCP yet, the REST API and /llms.txt cover the same surface. Pick the one your tool already supports — we’ll meet you there.