What is MCP (Model Context Protocol), and what does it mean for project management?

MCP, the Model Context Protocol, is an open standard for connecting an AI assistant to a tool or a source of information. A product that supports it publishes a short list of named actions, called tools, and any assistant that speaks MCP can call them. For project management it means your assistant stops working from text you pasted into a chat and starts working on the real board: listing tasks, reading one, adding one, moving one, commenting on one. What it may do is decided by the board, not by the assistant.

If you lead a team and do not write code, that paragraph is most of what you need. The rest of this piece fills in the detail and shows exactly what an assistant can do on a fenbs board through MCP, which is a short list.

The problem MCP solves

Before a shared standard, every connection between an assistant and a product was a one-off. Somebody had to build an integration for that particular assistant and that particular product, and when you changed either, you started again. For the person running the work it meant waiting for an integration to exist, or copying text between windows by hand.

MCP replaces the one-off with a common plug. A product runs an MCP server at an address. An assistant connects to that address, asks what tools are available, and gets back a list with a description of each. From then on the assistant can call those tools when you ask it to do something. The product does not need to know which assistant is calling, and the assistant does not need a special plugin for the product.

What an assistant can do on a fenbs board

fenbs is an MCP server. The connection guide lists eight tools, and that list is the whole of what a connected assistant can do with tasks. In the tool names a task is called an item; the two words mean the same thing.

• fenbs_whoami — who am I, and my role on every board. The assistant should call this first.
• fenbs_list_boards — the boards you are a member of.
• fenbs_list_items — the tasks on a board, filtered by lane, kind, assignee or free text.
• fenbs_get_item — one task and its comments, by ref.
• fenbs_create_item — add a task. It needs the permission to add tasks.
• fenbs_update_item — change a task’s lane, title, note or priority.
• fenbs_comment — comment on a task.
• fenbs_search — search across every board you can see.

The product guide at /llms.txt also describes two tools for AI context, fenbs_get_context and fenbs_add_context_note. AI context is the set of notes an assistant should read before it touches your work: what you are making, how you like tasks written, what must never be done. It is kept on the board rather than inside one assistant, so a new assistant reads all of it the moment it arrives.

Put together, a conversation looks like this. You ask what is on the board, and the assistant calls the list tool and reads you the answer. You ask it to move a task and note why, and it calls the update tool and the comment tool.

> move WEB-004 to doing and note that it is the drawer only

  fenbs_update_item  → WEB-004 backlog → doing
  fenbs_comment      → posted

  Done. WEB-004 is now In Progress.

What it cannot do, and how it knows

MCP is a way in. It is not a way round. On fenbs the MCP server calls the same permission checks as the interface a person uses, so an assistant can do exactly what the person it acts for can do, and is refused for exactly the same reasons, in the same words.

An assistant connects with a token issued under Settings, in Connect an AI assistant. The token acts as the person who issued it and inherits their board role, and it carries scopes of its own: read, write and comment. Both apply and the narrower one wins. A read-only token can list and search all day and will be refused the moment it tries to change anything.

When a call is refused, the result names the permission that was missing and the role the assistant holds. The assistant can then tell you plainly, rather than retrying or doing something adjacent.

{
  "error": "forbidden",
  "needed": "3503",
  "role": "Viewer",
  "message": "You are a Viewer on Clerkenwell Showroom,
              which cannot move tasks between lanes."
}

Why a team lead should care

You are not locked to one assistant

Because the connection is a standard one, the board does not care which assistant is on the other end. The fenbs site describes Claude, ChatGPT and Cursor working the same board at the same time. Changing assistants is one revoked token and one new one. The tasks, the refs and the history stay exactly where they are.

There is one copy of the work

Every assistant and every person is looking at the same row. There is no export step between tools and nothing to keep in sync, because there are not two copies to reconcile.

You can read what happened

Every change made through MCP is recorded with the name of the assistant that made it, alongside the changes people make. You can answer “what got completed this week, and who did it?” from History without asking anybody.

MCP and an API are not the same thing

An API is for programs: scripts, scheduled jobs, anything a developer writes by hand. MCP is for assistants, which discover the tools and decide when to call them. fenbs documents a REST API on the API page, and that page says plainly that API keys are not available yet and that MCP covers the same ground in the meantime. If you are connecting an assistant, MCP is the route to use today.

Connecting one

In Claude Code it is one command, followed by /mcp and choosing fenbs. In Claude on the web you add fenbs.ai as a connector in your settings. The full steps are in how to connect Claude to your project board with MCP.

claude mcp add --transport http fenbs https://fenbs.ai/api/mcp

MCP does not make an assistant wiser, and it does not decide your priorities. What it does is remove the copying and pasting between the assistant and the place your work lives, and put the question of what the assistant may do where it belongs: with the board, under your control.