The Model Context Protocol (MCP) is an open protocol for connecting AI applications to tools and data through a consistent interface. Anthropic introduced it in late 2024, and the project now publishes an open specification and documentation.
TL;DR
- MCP is a protocol (not a product) that defines how an AI client discovers and calls tools a server exposes.
- A server advertises typed tools; the model decides when to call them; results come back as context.
- It can reduce bespoke integrations: one server can work with multiple compatible clients, subject to the transports and features each client supports.
The problem MCP solves
Without a shared protocol, connecting an agent to a task tracker often means maintaining client-specific tool definitions, configuration, and authentication. Each additional client increases that integration surface.
MCP standardizes how a server describes and exposes capabilities. A compatible client can connect without a separate business integration, although setup and supported features can still differ by client.
How an MCP server works
A server exposes three kinds of capabilities:
- Tools — functions the model can call (
createTask,searchRepos). - Resources — data the model can read (a file, a record).
- Prompts — reusable prompt templates.
For task management, tools are the main capability. Each tool declares structured inputs and returns a result. The client makes available tools visible to the model; the model can propose or make a call based on the request and the client’s approval policy.
user: "create a task to fix the login bug"
→ model calls createTask({ title: "fix the login bug", priority: "major" })
→ server returns { id: 142, status: "Pending" }
→ model replies: "Created task #142, marked Pending."The model never “knows” your database schema. It knows the tools, and the server handles the rest. That separation is the whole point.
Why it matters for agents that act
A chat-only agent can talk about work. An MCP-connected agent can do work — and do it durably. When the task tracker is an MCP server, the agent’s actions land in a real system that outlives the session, that teammates can see, and that you can query.
A task board is a useful example because the result is durable and visible outside the conversation. The MCP task-management guide shows how that changes an actual workflow.
MCP vs. function calling — are they the same?
Not quite. Function calling is a model capability (the model emits structured arguments). MCP is a transport + discovery standard (how those calls reach your code and how the client learns what’s available). You typically use them together: MCP advertises tools; the model uses function-calling to invoke them. We dig into the comparison for the task-management case in the best MCP server for task management.
Getting started
The fastest way to feel it is to connect a server. The Kangram MCP setup is one config block, and within a session you’ll be creating and moving tasks from your agent. That’s a better intro than any diagram.
FAQ
Q: Is MCP only for Anthropic / Claude? A: No. Anthropic started it, but the spec is open and many clients support it (Cursor, OpenCode, Codex, Windsurf, and others). Adoption is broadening fast.
Q: Do I run the server locally or remotely?
A: Both models exist. A local server (e.g. spawned by npx) keeps secrets on your machine; a remote server is easier to share. Kangram supports the local-stdio shape, which is the most common for developer tools.
Q: Is MCP production-ready? A: Readiness depends on the server, client, transport, permissions, and data involved. Treat an MCP tool like any privileged integration: review access, limit credentials, require approval for risky actions, and monitor calls.