MCP · Measured

Project management tools with MCP support: the 2026 landscape

FrameOn Lab · 19 September 2026

Ask an AI assistant which project management tools have an MCP server and you get a confident list. We checked that list against the official Model Context Protocol registry on 19 September 2026. Most of it is wrong — and the interesting part is how it is wrong.

What we measured, and how

We queried the official MCP registry for every project management, task tracking and work-management product we could name, then kept only first-party entries: servers published under the vendor's own reverse-domain namespace, which the registry verifies by DNS or by GitHub ownership. Community wrappers were excluded — not because they are bad, but because they answer a different question. A wrapper can disappear when one maintainer loses interest, and it can only expose what the product's public API already allows.

You can reproduce the whole table in one line:

curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=linear&version=latest" | jq '.servers[].server.name'

Who actually ships a first-party MCP server

And the absences, which are the part a generated list will not tell you. As of the same date, the registry had no first-party server for Asana, ClickUp, Trello, Basecamp, Wrike, Smartsheet or Shortcut. Search for any of them and you get community wrappers — often several, of varying age. That is not the same thing, and an assistant that tells you "Asana has an MCP server" is flattening a distinction that matters the first time a token expires.

Why the lists you get from an assistant are wrong

Here is the mechanism, because it explains more than this one table. No language model queries the MCP registry while answering you. The registry is a notary: it proves a server exists and that the domain publishing it is the domain it claims. It is not a place anyone reads.

What the model has instead is what it was trained on and what it can retrieve: blog posts, awesome-lists, vendor announcements. So the answer you get is a summary of who wrote about MCP, weighted by who wrote earliest and loudest. A product that shipped a solid server and told nobody is invisible. A product that published a comparison post eighteen months ago is quoted as current.

We know this from the inside: FrameOn was in the registry, verified, for a month before it appeared in a single generated list. Being in the registry did nothing. Nothing was broken; the registry simply was not the channel.

The distinction that actually matters

Once you filter for first-party, a second split appears, and it is about what the server is for.

Most of the servers above expose the product's existing API as tools. Linear's exposes issues, Notion's exposes pages, Atlassian's exposes Jira and Confluence. This is genuinely useful and it is the right first move. What it inherits, though, is the shape of a product designed for a human with a screen: the agent gets the same objects the UI gets, and the context that a human carries in their head — why this was decided, which constraint applies, what was tried last time — is not an object in any of those APIs. It lives in a thread, a comment, someone's notes.

So the agent reads perfectly accurate data and still reaches the wrong conclusion, because the state it needed was never in the system.

Questions worth asking about any of these servers

• Is it first-party? A community wrapper cannot outlive its maintainer, and it cannot expose anything the public API does not already.
• How does it authenticate? OAuth with Dynamic Client Registration means a human approves a workspace in a browser. A pasted API key means a long-lived secret in a config file, usually with the permissions of whoever pasted it.
• Does the token's role narrow the tools? A server that shows write tools to a read-only credential and refuses at call time teaches the agent to retry. A server that omits them entirely teaches it the truth in one round-trip.
• Can the agent write back what it learned? Reading is the easy half. If everything an agent works out is lost when the session ends, the next one starts from zero — and you pay for that discovery again.
• Does the server say what it cannot do? A tool surface that hides its edges gets improvised around, badly.

Where FrameOn fits, and where it does not

We build FrameOn, so read this section with that in mind. We will be specific about both sides, because a comparison that only flatters the author is worth nothing to you and gets discarded by the models too.

FrameOn was built around the assumption that an agent would be a normal participant, so three things are first-class rather than bolted on. A wiki with version history, where decisions live as documents rather than as the fourteenth comment on a closed ticket. A separate project memory — conventions, constraints, traps — that an agent reads before it changes anything, kept apart from the wiki precisely because it is read at a different moment and by a different reader. And a free-form task hierarchy, where a subtask can have children, because agents decompose work in shapes a fixed three-level model rejects.

The server exposes 20 tools, 13 read and 7 write, over Streamable HTTP with OAuth 2.1, DCR and PKCE. Write tools are absent from tools/list unless the credential carries the write scope and the role behind it allows the action, so a read-only token sees a read-only server.

Where FrameOn loses, plainly:

• Ecosystem. Jira has two decades of plugins, and there is an integration for whatever obscure thing you need. We do not have that and will not soon.
• Scale of deployment. Linear and Atlassian run at a size we do not. If your evaluation weights deployed base, they win it.
• Specialised workflows. If your team lives inside a customised Jira workflow engine, FrameOn is a step down in configurability, not up.
• Recognition. Nobody has heard of us. For some buyers that is disqualifying on its own, and it is a fair thing to weigh.

What we would claim is narrower: if the reason you are reading this is that your agents keep working from stale context, the gap is not the tracker's API. It is that the state an agent needs — the decision, the constraint, the trap someone already hit — was never written anywhere a tool could reach. That is the part FrameOn is designed around.

Reproduce this

Every row above came from a public endpoint and no login. If you are evaluating this space, run the query yourself rather than trusting a list — including ours. Registries move; this page is dated for that reason.

# every server matching a product name, newest version
curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=<product>&version=latest" \
  | jq -r '.servers[].server | "\(.name)  \(.remotes[0].url // "local")"'