What is the Model Context Protocol and why does it matter for project management?
The Model Context Protocol (MCP) is a standard that lets AI agents discover and invoke tools exposed by external servers. Instead of hardcoding API calls into an agent's prompt, MCP allows the agent to connect to a server, enumerate its available tools, and call them with structured inputs and outputs. For project management, this means an AI agent can read your board, create cards, move work between columns, and add comments - all through a protocol it already understands.
Before MCP, connecting an AI agent to a project management tool required writing custom integration code: API client libraries, authentication handling, response parsing, and error recovery. Each tool needed its own integration, and each integration was fragile. MCP standardizes this. An agent that supports MCP can connect to Flux the same way it connects to a file system, a database, or a web browser - as a tool server that declares its capabilities.
Flux ships a built-in MCP server that exposes kanban board operations as MCP tools. This article explains how it works, what agents can do with it, and how to set it up with Claude Desktop, Cursor, and other MCP-compatible clients.
How does Flux's MCP server work?
The Flux MCP server runs as a lightweight process that authenticates against the Flux API using a standard API key. When an MCP client connects, the server advertises a set of tools - each representing a board operation. The client can then invoke these tools as part of its reasoning and task execution.
The architecture is intentionally simple. The MCP server is a thin translation layer between the MCP protocol and the Flux REST API. It does not maintain its own state, cache board data, or make autonomous decisions. Every tool invocation maps to one or more API calls to the Flux backend, which handles authentication, authorization, idempotency, and conflict detection the same way it handles any other API request.
This means the MCP server inherits all of the Flux API's guarantees: scoped permissions via API keys, optimistic concurrency with version checking, idempotent writes via the X-Idempotency-Key header, and full audit trail in the activity log. When an AI agent creates a card via MCP, that action shows up in the activity log with the API key's attribution, exactly as if a CI script had created it.
Available tools
The MCP server exposes the following tools to connected agents:
- list_boards - Returns all boards accessible to the API key, including column structure, card counts, and board metadata.
- get_board - Returns a single board with full column and card data. Cards include titles, assignees, labels, due dates, and checklist progress.
- create_card - Creates a new card in a specified column with title, description, labels, assignees, and optional due date.
- update_card - Modifies an existing card's properties including title, description, column (for moves), assignees, and labels.
- add_comment - Adds a comment to an existing card, useful for agents that want to leave context about actions they have taken.
- list_labels - Returns available labels for a board, so the agent can apply the correct labels when creating or updating cards.
Each tool includes a structured schema that describes its inputs and outputs. MCP clients use these schemas to understand what arguments each tool requires and what response format to expect. This allows agents to invoke tools correctly without hardcoded knowledge of the Flux API.
What can AI agents actually do with a kanban board?
The interesting question is not what tools are available but what workflows they enable. Here are the use cases we have seen teams implement since launching the MCP server.
Autonomous coding agents
The highest-leverage use case is connecting a coding agent - such as Cursor or Claude with tool use - to both your codebase and your Flux board. The workflow:
- The agent reads the top card from your Backlog column via
get_board. - It parses the card's title, description, and checklist items to understand the requirements.
- It implements the feature or fix in your codebase.
- It moves the card to the Review column via
update_card. - It adds a comment to the card with a summary of what was implemented and a link to the PR via
add_comment.
This is not a hypothetical. Teams using Cursor with Flux's MCP server are running this workflow today. The agent does not replace the developer - it handles the mechanical parts (reading requirements, updating the board, writing the PR description) so the developer can focus on the implementation decisions that require human judgment.
Automated triage
Bug reports arrive as cards in a triage column, often with minimal description. An AI agent connected via MCP can read each new card, analyze the description against known patterns, and apply appropriate labels - severity (P0, P1, P2), area (frontend, backend, infrastructure), and type (regression, new bug, enhancement). It can also add a structured comment with its analysis, giving the triaging engineer a head start.
Weekly board review
A scheduled agent runs weekly, reads all boards via list_boards and get_board, and generates a summary: cards that have been in progress for more than five days (potential blockers), columns that exceed their intended WIP limits, cards with overdue dates, and overall throughput trends. The summary can be posted as a comment on a designated "meta" card or sent to Slack.
Cross-system synchronization
When a customer reports an issue in your support tool, an agent creates a card in Flux with the relevant context. When a card reaches Done in Flux, the agent updates the support ticket. This bidirectional sync eliminates the manual handoff between support and engineering that causes tickets to fall through the cracks.
How do you set up the MCP server?
Setup takes under five minutes for any MCP-compatible client. The general steps:
- Generate an API key. In Flux, go to Settings and create an API key with
readandwritescopes for the workspace you want the agent to access. - Install the MCP server. The Flux MCP server is distributed as an npm package. Install it globally or as a project dependency.
- Configure your MCP client. Add the Flux MCP server to your client's configuration file, providing the API key and your Flux instance URL.
The exact configuration varies by client. For Claude Desktop, you add an entry to the claude_desktop_config.json file. For Cursor, you add it to the MCP settings panel. The MCP documentation page has copy-paste configurations for each supported client.
How does MCP handle security and permissions?
Security is the first question teams ask about giving AI agents access to their project boards, and rightly so. The Flux MCP server inherits the API key permission model, which provides several layers of control.
- Scope restrictions. API keys can be limited to
readonly orread+write. A read-only key lets an agent analyze board state without modifying it. - Workspace scoping. Keys can be scoped to a specific workspace, preventing the agent from accessing boards in other workspaces even if they belong to the same account.
- Audit trail. Every action taken via MCP is recorded in the activity log with the API key's identity. You can see exactly which cards were created, moved, or modified by the agent, and undo any action with one click.
- Revocation. API keys can be revoked instantly from the Settings page. Revoking a key immediately cuts off the MCP server's access.
The event-sourced activity log is particularly important in the MCP context. When an AI agent makes a mistake - creates a card in the wrong column, applies the wrong label, moves a card it should not have - you can see exactly what it did and undo it. This makes experimentation safe: try the agent, review what it does, and undo anything that is wrong.
When should you use MCP versus the REST API directly?
The MCP server and the REST API are complementary, not competing. The decision depends on who or what is making the calls.
| Use case | Best approach | Why |
|---|---|---|
| CI/CD pipeline automation | REST API | Deterministic scripts with known inputs and outputs |
| AI coding agent (Cursor, Claude) | MCP server | Agent needs tool discovery and structured invocation |
| Custom Slack bot | REST API | Fixed integration logic, no reasoning required |
| Autonomous triage agent | MCP server | Agent reasons about card content and applies judgment |
| Dashboard / reporting | REST API | Read-only data aggregation with known queries |
| Natural language board management | MCP server | User describes intent, agent translates to actions |
The rule of thumb: if the caller is a script with deterministic logic, use the REST API. If the caller is an AI agent that reasons about what to do, use the MCP server. Both hit the same backend, both are authenticated the same way, and both produce the same audit trail.
Where is MCP heading for project management?
The current MCP server covers the core board operations. We are expanding it in three directions.
First, richer read operations: agents that can query the activity log to understand project history, read checklist items to understand task breakdown, and access attachment metadata. Second, batch operations: creating multiple cards in one tool call, moving multiple cards between columns, and applying labels in bulk. Third, event subscriptions: allowing agents to receive notifications when board state changes, rather than polling. This would let an agent react to card movements in near-real time - for example, automatically running tests when a card moves to Review.
The broader trend is clear. AI agents are becoming first-class participants in the software development workflow, and project management tools need to treat them as users, not just integration targets. MCP is the protocol that makes this possible, and Flux's MCP server is how your board participates.