Give your coding agent a task board over MCP

A coding agent with no task list does whatever the last message said, then stops. It doesn't know what's next, what's already done, or what the human still owes it. You become the task list: re-reading old chats, pasting context, deciding what to ask for.

The fix is to give the agent a board it can read and update itself. With the Model Context Protocol (MCP), that board becomes a set of tools the agent calls like any other: "what should I work on", "I'm starting this", "this criterion passes", "I'm done, please review". This guide explains how that works, what makes a board useful to an agent, and how to set one up.

What MCP adds

MCP is an open protocol for connecting AI applications to tools and data. An MCP server exposes tools with names, descriptions and input schemas; an MCP client (Claude Code, Cursor, Codex, VS Code, Claude.ai, ChatGPT and many others) lists those tools and lets the model call them.

For project management, that means the agent doesn't need a browser or an API key pasted into the chat. It calls get_next_work the way it calls a file-read tool, and gets back structured text it can act on.

Most clients connect to a remote MCP server with a URL and either a bearer token or an OAuth sign-in. For example, in Claude Code:

claude mcp add --transport http klio https://klio.dev/api/mcp

What an agent needs from a board

A board designed for people shows cards, columns and assignees. An agent needs different things, because it reads everything literally and starts every session with no memory.

A clear next item

"Continue" should mean one specific story, not "look around and decide". The board should pick the next story by priority and order, skip stories that are waiting on unfinished work, and reserve it briefly so two agents asking at the same moment don't get the same one.

Acceptance criteria

The agent needs to know when it's done. A story with three checkable criteria ("an expired link shows a 'request a new one' page") ends when they pass. A story without them ends when the agent feels finished, which is usually too early or far too late. See acceptance criteria for AI coding agents.

Claims

When an agent starts a story, it should hold it. Another agent asking for work should get something else, and a human looking at the board should see who has what.

A review step

Agents should be able to say "ready for review" but not "done". Keeping the last step human is what keeps a board trustworthy after a few weeks of autonomous work.

A hand-off channel

Some steps are only yours: creating an API key, adding a DNS record, approving a cost. The agent needs a way to put those in front of you with exact steps, instead of leaving a TODO in the code or stopping without saying why.

A short project summary

Every new session should start with two or three sentences: where the project stands, what was last done, what's next. Long transcripts don't work for this; a curated note does.

Issue tracker over MCP, or a board built for agents?

If your team already lives in GitHub Issues, Linear or Jira, connecting it over MCP is a reasonable first step. Linear and Atlassian publish official MCP servers, and GitHub has one too. The agent can search, read and update issues.

What you don't get by default is the agent-specific behaviour above: a "next item" tool, claims between agents, criteria the agent ticks as it goes, a review gate, or a resume note. You can approximate some of it with labels and conventions in your rules file, and for a team with an established process that may be the right call.

A board built for agents bakes those into the tools themselves. It's often the better fit for solo builders and small teams whose "process" is mostly agents doing the work.

The loop, step by step

Here's what one story looks like with Klio, the board this site is about. The tool names are Klio's; the shape is what matters.

1. Plan. You say "add password reset". The agent calls brief_feature to read the stack and existing features, proposes a feature with four stories and their acceptance criteria, and saves it with create_feature once you agree.
2. Pick up. You say "continue". The agent calls get_next_work and gets a short digest of what changed, the resume note, and the next story, reserved for it.
3. Claim. start_issue moves the story to In Progress and returns its criteria, the files likely involved, and the project's working agreement (for example "run the tests before completing").
4. Work. The agent writes code and calls check_criterion as each criterion really passes. Decisions go in add_comment.
5. Hand off. It needs a Resend API key in production, which only you can create. It calls flag_for_human with the exact steps. You see it in your inbox.
6. Finish. complete_issue posts a short summary, moves the story to In Review, rewrites the resume note, and can claim the next story in the same call.
7. Review. You look, and move it to Done.

Every call leaves a trace on the board, so you can see what each agent did without reading their transcripts.

Connecting the board

Klio's MCP server is at https://klio.dev/api/mcp. Clients with MCP sign-in (Claude.ai, ChatGPT, Claude Code, Codex, Cursor, VS Code and others) need only the URL: they find the OAuth metadata from the server's 401 response and open a browser for you to approve. Clients without it use a token from Settings. Per-client steps are in the docs and the full tool list is in the MCP tools reference.

Then add a few lines to your repo's rules file so every request goes through the board, not just the first (see CLAUDE.md vs AGENTS.md).

What a story looks like to the agent

When an agent calls start_issue, it should get everything it needs in one response, so it doesn't have to go looking. In Klio that's roughly:

SNIP-12 · Clicks-by-day chart on the link page
Feature: SNIP-F3 · Link analytics
Status: In Progress · Priority: High · 3 pt

Acceptance criteria
- [ ] 30-day line chart with tooltips
- [ ] Empty state for links with no clicks yet
- [ ] Works at 360px

Likely files
- src/app/links/[id]/chart.tsx

Working agreement
- Run npm test before completing

Short, literal and complete. Compare that with an issue written for people, which might be a paragraph of background, a screenshot, three linked discussions and no clear end state. Both have their place; only one is easy for an agent to act on.

Questions to ask before choosing a board

• Does it tell the agent what's next, or does the agent have to decide?
• Can two agents work at once without taking the same task?
• Where does "done" live? If agents can close their own work, the board will drift from reality.
• How do hand-offs reach you? A comment buried in a ticket is easy to miss.
• Which clients does it support? You'll likely use more than one agent. Anything that speaks MCP should work.
• What does it store? Plans, progress and env var names are fine. Secret values should never be on a board.
• What happens when you come back after a month? The answer should be "read a short note and continue", not "re-read everything".

Security basics for agent boards

Giving an agent write access to anything deserves a little care:

• Scope tokens. Give an agent access to the projects it works on, not your whole workspace. Klio tokens and OAuth grants can be limited to chosen projects.
• Read-only where possible. A research or review agent doesn't need write tools. Read-only connections in Klio only list read tools, and writes are refused.
• Never let agents handle secret values. The board should store which environment variables exist and where they're set, never the values. Klio stores names only.
• Revoke what you don't use. Connections should be visible and revocable in one place.

Getting more out of it

• Write small stories. One session, one story. It keeps progress unambiguous.
• Order your stories. Use dependencies ("this waits on that") so "continue" never picks something that can't be done yet.
• Assign work when several agents run. Hand a whole feature to one agent and another feature to a second, so they never collide.
• Read the activity, not the transcripts. The board's history tells you what happened in a fraction of the time.