An MCP server exposes your software as a set of callable tools that an AI assistant can invoke directly. MCP stands for Model Context Protocol, an open standard for connecting assistants to external systems. Instead of the assistant reading a screenshot of your backlog and describing it, it calls create_task and the task exists.

That distinction is the whole point, so it is worth being precise about it.

The difference between “AI features” and an MCP server

Most tools that advertise AI have added a language model inside their interface. It summarises a document, drafts a description, suggests a title. Useful, but the assistant is a guest in one vendor’s window, and it can only touch what that vendor exposed to it that week.

An MCP server inverts the arrangement. The product publishes its operations as tools, and whichever assistant you already use calls them. There is no new chat window to learn, no second place to check, and the same assistant can span several systems in one instruction.

What a tool call actually is

A tool is a named function with a typed schema and a description. When an assistant decides to use one, it sends a structured call and receives a structured result. Nothing is scraped and nothing is guessed from pixels.

In Planner.day there are 32 such tools, covering roughly what the interface covers: creating and updating tasks, changing status, assigning people, managing tags, searching, commenting, and reading dashboards and analytics.

The part everyone should ask about: permissions

The reasonable objection to giving an assistant write access is that it will do something you did not intend, at a scale a human never could.

Three things make that tractable:

Tool calls use the same authorization path as the UI. There is no faster, looser API behind the assistant. Every call resolves the same permissions, runs the same validation and writes the same activity record. If a person could not do it, the assistant cannot either.

A token’s authority is bounded twice. It carries a scope set — tasks:read, tasks:write, comments:write and so on — and a list of workspaces it may touch. The effective authority is the intersection. A token scoped to read tasks in one workspace can do exactly that and nothing else.

Nothing administrative is reachable. No token can perform a super-admin action, including minting more tokens. That ceiling is not a policy someone can misconfigure; it is enforced in the pipeline.

Presets, because scope lists are easy to get wrong

Asking an administrator to hand-pick from 22 scopes invites over-granting. Four presets cover the realistic cases:

read_only_analyst — can look at everything it is given, change nothing
task_bot — creates and updates tasks, cannot touch members or structure
pm_bot — the above plus dashboards and analytics
full_access — everything the token’s workspaces allow

Connecting one

claude mcp add --transport http planner \
  https://api.planner.day/api/mcp \
  --header "Authorization: Bearer tvmcp_…"

That is the whole setup. The assistant discovers the available tools itself, filtered to what the token’s scopes actually permit — so it never advertises an action it would be refused.

What this changes day to day

The honest answer is that it removes transcription. Standing meetings produce decisions that someone then types into a tool. Bug triage produces a verdict that someone then clicks. With tool access the assistant that already heard the decision can record it, and the person who would have typed it can go and do something else.

That is a smaller claim than “AI runs your project”, and it is the one we can actually stand behind.