Managing tasks with the Model Context Protocol (MCP)

Managing tasks with the Model Context Protocol (MCP) means giving an AI agent a persistent, structured task board it can call as a tool — instead of relying on the chat history as a scratchpad. This guide covers what that changes, how to set it up, and why it’s becoming the default for AI-native teams.

TL;DR

MCP lets an AI agent call external tools. When a task tracker exposes itself as an MCP server, the agent can create, read, update, and move tasks like any other function call.
This beats pasting TODOs into chat because tasks survive context limits, are queryable (list tasks assigned to ivan), and sync with your team — humans see the same board.
Setup typically requires a client configuration and Kangram credentials. Exact steps and supported transports vary by client.

What is MCP, in one paragraph

The Model Context Protocol is an open protocol for connecting AI applications to tools and data sources. A server advertises capabilities such as tools with structured inputs, and a compatible client makes them available to the model. If the protocol is new to you, start with the MCP primer or the official documentation.

Why agents need a task board

Agents are good at doing a task and bad at remembering fifty of them. Three failure modes show up constantly:

Context loss. A long session evicts earlier context. The “TODO: fix login bug” the agent noted 40 messages ago is gone.
No shared state with the team. Work the agent did lives in your 1:1 chat. A teammate can’t see it, pick it up, or verify it.
No queryability. You can’t ask “what’s in progress and assigned to ivan?” of a chat log. You can of a task board.

An MCP task tracker fixes all three: state lives outside the model, it’s shared, and it’s queryable.

How MCP task management works

The agent doesn’t store tasks. It calls tools:

createTask(boardId, title, priority, assignee)   → Task #142
listTasks(boardId, assignee?, status?)            → [Task, Task, …]
updateTask(id, status?)                           → Task
moveTask(id, targetBoardId)                       → Task

Because these are typed tool calls, the model reasons about them reliably — far more reliably than “remember to do X later.” And because they hit a real backend, the result is durable and visible to everyone.

Setup: connect a task-tracker MCP server

Using Kangram as the example (any MCP task server follows the same shape):

1. Create a board in Kangram (web or @KanGramBot on Telegram).

2. Generate an API key in Settings → API keys.

3. Add the server to your client config:

mcp_servers:
  kangram:
    command: npx
    args:
      - kangram-mcp@latest
    env:
      KANGRAM_API_KEY: your-api-key

4. Ask your agent, in plain language:

> Create a task: fix login bug in board 15, assign to ivan
✓ Task #142 created · status: Pending · assignee: @ivan

> List all tasks assigned to ivan
✓ 4 tasks: #138 #140 #141 #142

> Move task 42 to Done
✓ Task #42 → Done

That’s the whole loop. See the step-by-step Claude walkthrough for screenshots and edge cases.

MCP vs. function-calling vs. pasting TODOs

Approach	State survives?	Shared with team?	Queryable?
Paste TODOs in chat	❌ lost on context eviction	❌	❌
Custom function calling	⚠️ only if you build persistence	only if you build sharing	only if you build it
MCP task server	✅	✅	✅

You can wire model function-calling directly to a database. That gives you full control, but your team must own persistence, authorization, tool discovery, client integration, and a human interface. MCP standardizes part of that integration surface. The task-server evaluation guide explains when adopting or building is the better fit.

One backlog for humans and agents

This is the operational goal: the board your Telegram team uses is also the board your agent updates. An agent creates task #142, a teammate picks it up in the kanban view, and either participant can update its status. The task—not the chat transcript—holds the shared coordination state.

It’s why we built Kangram with a single command layer (UCL) powering the MCP server, REST API, CLI, and the Telegram bot off one set of definitions — so the surface an agent uses and the surface a human uses never drift.

For operating details:

Use the MCP security checklist before granting write access.
Adopt the async human-agent handoff format for work that crosses sessions or time zones.
See the Telegram and AI-agent workflow for one shared capture, execution, and review loop.

FAQ

Q: Do I need the web app to use the MCP server? A: No. The MCP server, Telegram bot, and web app all talk to the same backend. You can run entirely from your agent or Telegram.

Q: Which clients are supported? A: Compatibility depends on Kangram’s current transport and each client’s MCP implementation. Use the setup page for the currently verified path; do not assume identical configuration or approval behavior across clients.

Q: Is my task data shared with the model provider? A: Tool calls return data to the model in the current session, like any tool use. Your board itself isn’t exported anywhere.

Q: Does it work offline / self-hosted? A: The server talks to the Kangram backend. Self-hosting is on the roadmap — talk to us.

Next steps

Try the Kangram MCP server — setup in 60 seconds.
Read the primer: what is the Model Context Protocol.
Follow the Claude + task management walkthrough.

The shift is small — one config block — but it changes how agents and teams coordinate. The chat log stops being a project manager and goes back to being a conversation.