Issue trackers with MCP support, compared.

The MCP story

Who ships the MCP server, how it connects, and what an agent actually gets once it's wired up.

The context bill: tool counts and token costs

Tool definitions are not free. Every MCP server an agent connects to injects its full tool schemas into the context window before any work happens. The MCP project's own client guidance is blunt about it: loading every tool definition up front "wastes tokens, increases latency, and degrades model performance", and it suggests budgeting tool definitions to roughly 1 to 5 percent of the context window. On a 200k-token model, that is 2k to 10k tokens. Anthropic's guidance for tool authors is shorter: "More tools don't always lead to better outcomes."

So we measured, on July 14, 2026: each server launched over stdio, asked for its tool list, schemas tokenized. Numbers below are what an agent pays before it reads a single line of your code.

Four of the five measurable servers fit the budget. beads deserves specific credit for the smallest bill: its server hides most commands behind a discover_tools call instead of declaring everything up front. (That same design means its measured number understates the eventual cost, since full schemas load on demand.) Plane is the outlier. 139 tools and thirty thousand tokens is 15 percent of a 200k context spent before any work starts, and it exceeds VS Code's 128-tools-per-request cap on its own. The count is not padding, it is philosophy: in our dump, five of every six Plane tools are create, read, update, or delete variants spread across about two dozen entity types, from work items down to estimate points and property options. That is an API mirror, and agents pay for the whole mirror up front. Linear's hosted server sits behind a workspace login, so we cite the published count instead of measuring it ourselves; Linear also revises its tool set regularly.

Lific's own 5.6k fits the budget, but not gracefully: per tool, its schemas are the second wordiest on this page, after Plane.

Methodology: each server was launched over stdio on July 14, 2026, sent initialize and tools/listvia the official MCP Python SDK, and the returned tool definitions (name, description, input schema) were serialized as compact JSON and tokenized with tiktoken's o200k_base. Clients serialize schemas differently, so treat small deltas as noise; the order of magnitude is the point.

Running it

What you deploy, where the data lives, and under what terms.

Where Lific wins

• The tracker is the MCP server.

  Not a wrapper, bridge, or sidecar. The same binary that stores your issues speaks MCP, so the tools and the data can't drift apart, and there is no second process to install, version, or babysit.

• Verbs shaped for agent loops.

  workable returns issues with no unresolved blockers in one call. edit_issue patches by exact string replacement instead of resending whole descriptions. Plans are nestable step trees that mirror issues and survive across sessions and context compaction.

• A small context bill.

  About 5.6k tokens for the full 27-tool surface, roughly one long file read, so connecting the tracker doesn't crowd out the actual work.

• Humans get a real UI in the same binary.

  Issue list, kanban board, documents, and comment threads where you and your agents talk to each other, at localhost:3456, no extra deployment.

• An audit trail that names the door.

  Every change records who made it and whether it came through the web UI, MCP, the REST API, or the CLI. When an agent goes off script, you can see exactly what it did.

• Setup is one minute, not one afternoon.

  lific init writes config, creates the database, registers a background service. lific connect detects your AI clients and writes their MCP config. lific doctortells you what's broken.

• Apache-2.0, no telemetry, no account.

  Permissive license, nothing phones home, and keys minted from your own shell never require a signup.

Where Lific loses

Everything above is true, and so is this. If one of these is a dealbreaker for you, the next section points you somewhere good.

• No prebuilt Windows binary.

  Releases cover Linux and macOS (x86_64 and arm64). Windows works natively, but you compile it yourself with cargo install lific. There is also no Windows service integration, so keeping the server running is on you (Task Scheduler or a terminal).

• No repo-local mode.

  Issues live in a server database, not in your repository. If you want the tracker versioned with the code (branching with it, merging with it, readable offline in the checkout), beads does exactly that and Lific does not.

• A server is required.

  Lific is an always-on service. If the process is down, so is the tracker. beads needs no server at all; Linear runs someone else's.

• Single maintainer.

  The bus factor is one. That is a real risk and you should price it in.

• Young.

  First release April 2026. Short track record, small community. Weight that honestly against tools that have shipped for years.

• Sized for solo developers and small teams.

  SQLite on one box, project-scoped roles, and that's the ceiling. If you need SSO, org hierarchies, or enterprise scale, Plane and Linear are built for that and Lific is not.

• No hosted option.

  There is no cloud to sign up for. You run it, or it doesn't exist.

Questions people actually ask

This page is a snapshot: every claim above was checked against the linked sources on July 14, 2026, and products ship faster than pages update. If a cell is wrong or has gone stale, file an issue and we'll fix the cell and the date.