What to look for in an MCP server for project management

A year ago connecting an AI assistant to your task tool meant a plugin, if you were lucky. Now most tools publish an MCP server, and the assistant you already use — Claude, ChatGPT, Cursor, Claude Code — can call it. That is good. It also means the question has moved. The question is no longer “can I connect it?” but “what happens when I do?”, and the tool lists on the directory pages do not answer it. Here is what does.

1. How does the assistant sign in?

There are two answers. The first is an API key: you generate it in the tool, paste it into a config file, and the assistant presents it. It works, and it has two problems. The key is now in a file on disk, in shell history, and in whatever config sync you use; and it acts exactly as you, invisibly, so nothing the assistant does can be told apart from what you did. The second answer is OAuth: the assistant opens the tool in your browser, you sign in and approve, and the assistant is handed a token it keeps. Nothing is copied. The token is listed by name in the tool and can be revoked without touching your own login. Prefer the second, and be suspicious of a server that only offers the first.

2. Whose permissions does it get?

The honest default is “yours”: the assistant can do what you can do. The useful question is whether that can be narrowed. Can you approve an assistant with read only? Can you give it a role that adds and comments but never moves or deletes? If the answer is that the assistant gets your full access or nothing, you will connect it with your full access, and the first time it is thorough about something you will wish you had not.

3. Is its work signed?

Open the tool’s history after the assistant has done something. Does the entry say the assistant did it, or does it say you did? A history that records “Claude via Sam Ade moved BU-014 to In Progress” lets you review a day of agent work in minutes and undo the one move that was wrong. A history that says Sam did it makes the assistant’s work indistinguishable from your own, which is the same as having no history at all.

4. What does a refusal look like?

Assistants will be refused: they ask for things their role does not allow. A good server answers with a sentence the assistant can repeat to you — “You are a Viewer on Kitchen Refit, which cannot move tasks between lanes.” A bad one answers with a status code, and the assistant either guesses a workaround or tells you something went wrong. The difference shows up in the first five minutes of use and decides whether you trust the assistant on the board at all.

5. Can the assistant find out what it may do?

Look for a tool like whoami: who am I acting as, and what is my role on each board? An assistant that can ask that first will not spend ten calls discovering by trial what it is not allowed to do. It is a small thing that separates servers built for agents from servers built to tick the MCP box.

6. Is the vocabulary small enough for an assistant to use well?

A tool with forty issue types, custom fields per project and configurable workflows gives the assistant forty ways to file something wrong. A tool with three kinds of task and four lanes gives it three. Simplicity is not a nicety for agents; it is accuracy.

7. Does context travel with the board?

The assistant needs to know how you work: naming, rules, where things are. If that knowledge lives only in one assistant’s memory or one rules file, switching assistants starts from zero. A server that offers the board’s own context — readable by every assistant that connects, and writable by them when they learn something — keeps the knowledge with the work.