Servidor MCP para gestão de projetos: checklist de 10 pontos, com notas

Um bom servidor MCP para gestão de projetos deixa um cliente de IA ler e alterar o seu quadro sem uma chave que você precise vigiar, permite cortar um cliente sem mexer nos outros e dá aos agentes um jeito seguro de assumir trabalho, fazer perguntas a você e provar o que fizeram. A seguir estão dez verificações que cobrem isso, por que cada uma importa e uma tabela com notas para Weft, Hypertask, Linear, Trello e Notion.

Nós fazemos o Weft. Os fatos sobre outros produtos vêm das páginas oficiais deles, verificadas em 27 de outubro de 2026. Quando a página não informa, a tabela diz "Não informado".

Por que dar nota a um servidor MCP de gestão de projetos?

O Model Context Protocol resolve o encanamento: um cliente pergunta a um servidor quais ferramentas existem e as chama com argumentos estruturados. Ele não diz nada sobre quanto tempo um token dura, se dois agentes podem pegar a mesma tarefa ou o que acontece quando um agente quer excluir algo. Essas são decisões de produto, e elas variam muito de um servidor para outro.

O guia do Hypertask sobre servidores MCP de gestão de projetos tem uma lista de avaliação sensata: cobertura de ferramentas, qualidade do schema, autenticação e escopo, histórico de auditoria, ações destrutivas, transporte. Só que ele nunca a preenche. Este post pega uma lista parecida, afina em dez verificações que se respondem com sim ou não e preenche as respostas, inclusive as nossas.

Quais são as dez verificações?

1. Como você faz login e quanto tempo o token dura?

Uma chave que você copia para um arquivo de configuração é uma senha guardada no disco, e quando ela expira o seu agente falha sem alarde no meio de uma execução. OAuth com refresh tokens significa nada para copiar e nenhum lembrete na agenda para renovar. Pergunte a validade do token de acesso e da conexão, não só o método.

2. Dá para revogar um cliente sem derrubar a sua conta?

Você vai conectar vários clientes: um app de chat, um agente de código, talvez um celular. Quando um deles se comporta mal ou um notebook é perdido, você quer cortar aquela conexão e deixar as outras funcionando. Se a única alavanca é trocar uma chave compartilhada, todos os clientes quebram de uma vez.

3. Cada conexão pode ter o seu próprio nível de permissão?

Um cliente que você usa para perguntar "o que tem no meu quadro?" não precisa de acesso de escrita. Um agente de código precisa de escrita, mas raramente precisa arquivar em massa. Níveis por conexão, como read, write e full, permitem dar a cada cliente o mínimo de que ele precisa, e essa é a melhor defesa contra um agente confuso ou manipulado.

4. As ações destrutivas são marcadas e limitadas?

Ferramentas MCP podem trazer indicações que dizem se uma ferramenta é somente leitura ou destrutiva, e os clientes podem usá-las para pedir confirmação antes de agir. Verifique se o servidor as define com honestidade e o que "excluir" realmente faz: uma lixeira de onde dá para restaurar é muito diferente de uma exclusão permanente.

5. Um agente consegue assumir uma tarefa para que dois agentes não trombem?

Mover um cartão para Doing é um sinal visual, não uma trava. Dois agentes que leem o quadro com um segundo de diferença vão ver a tarefa livre e os dois vão começar. Um claim com lease, decidido pelo servidor, faz o segundo agente receber um não, e um lease que vence quando um agente morre libera a tarefa para outro.

6. O agente consegue fazer uma pergunta estruturada a você?

Os agentes esbarram em bifurcações que só uma pessoa pode decidir. Sem uma ferramenta para isso, o agente chuta ou para, e a pergunta morre num histórico de chat. Uma pergunta estruturada, com opções, entregue num lugar onde você realmente vai vê-la, mantém a decisão presa à tarefa.

7. A conclusão traz evidências?

"Pronto", vindo de um agente, é uma afirmação. Uma conclusão que registra links, hashes de arquivos ou outros artefatos, além do que não foi feito, permite que você confira o trabalho sem refazê-lo. O quadro também deve mostrar qual cliente fez o trabalho.

8. Quais clientes conseguem chegar até ele de fato?

Um servidor só é tão útil quanto os clientes que você já usa. Confira o caminho real em cada um: um app publicado no ChatGPT, um conector personalizado ou uma página no diretório do Claude, uma configuração de uma linha no Claude Code, no Cursor e no Codex. Confira também se a pergunta do agente consegue chegar a você, a pessoa, no celular.

9. O que o plano gratuito permite via MCP?

Agentes fazem muitas chamadas pequenas. Um plano gratuito que conta quadros, tarefas ou chamadas pode acabar no meio da semana. Descubra o limite exato, e se o MCP sequer está incluído no plano gratuito, antes de criar um hábito em cima dele.

10. O transporte está atualizado?

A especificação do MCP evolui. O transporte remoto atual é o Streamable HTTP, e endpoints SSE mais antigos estão sendo descontinuados por vários fornecedores. Um servidor que informa as revisões da especificação que suporta é mais fácil de confiar quando o seu cliente atualiza.

Que notas tiram Weft, Hypertask, Linear, Trello e Notion?

Cada célula usa só o que a página do próprio fornecedor ou o servidor em produção dizem. "Não informado" não quer dizer que o recurso falta; quer dizer que não conseguimos confirmá-lo hoje numa fonte oficial.

Algumas observações honestas para ler a tabela. Linear, Trello e Notion são produtos amplos, em que o servidor MCP é uma interface entre muitas, e a documentação do MCP deles não descreve ferramentas de fluxo para agentes, como leases ou perguntas estruturadas; por isso muitas linhas específicas de agentes ficam em branco. A recusa do Trello em expor exclusões permanentes é uma boa escolha de segurança. O endpoint somente leitura separado do Linear é um jeito limpo de cumprir a verificação 3. Se o seu time já vive numa dessas ferramentas, o servidor oficial costuma ser o melhor começo; veja Weft vs Linear, Weft vs Trello e Weft vs Notion.

O Hypertask traz lease, evidências e escalação no produto, mas a documentação do MCP dele diz que isso fica na API REST, não no MCP, por design. Funciona bem se os seus agentes rodam scripts. Significa que um cliente de chat conectado só via MCP não tem acesso a isso. O Hypertask também tem coisas que o Weft não tem: uma CLI para scripts e CI, uma API REST, agentes como contas de serviço com identidade própria, recursos de IA embutidos, controle de tempo e uma interface pensada para o teclado. A nossa comparação mais longa está em alternativa ao Hypertask.

Em que o Weft não vai bem?

O servidor MCP do Weft tem 32 ferramentas, e listá-las não sai barato: medimos a resposta de tools/list em cerca de 17,7 mil tokens. A referência das ferramentas do Hypertask agrupa as ferramentas por ação, então 21 ferramentas cobrem mais operações, cada uma com um campo action. É uma troca real. Ferramentas agrupadas ocupam menos espaço no contexto do modelo. Ferramentas separadas permitem que cada uma traga a sua própria indicação de somente leitura ou destrutiva, e é isso que faz uma conexão read significar exatamente 11 ferramentas somente leitura e uma conexão write significar tudo menos as 3 destrutivas. Escolhemos o segundo caminho; se o seu cliente tem pouco contexto sobrando, o primeiro pode servir melhor.

Outras lacunas, sem rodeios. O Weft não tem CLI, nem API REST pública, nem webhooks, então não pode ser acionado por um job de CI sem um cliente de IA. Não há integração com GitHub ou Slack. Tokens de acesso pessoal não têm escopos: um token alcança as 32 ferramentas em todo o workspace, então prefira OAuth quando o seu cliente aceitar, porque os níveis por conexão valem só para conexões OAuth.

Como se proteger contra prompt injection?

Um agente que lê texto de tarefas, comentários ou páginas vinculadas pode ser guiado por instruções escondidas ali dentro. O MCP não resolve isso; a sua configuração resolve. Três hábitos ajudam.

• Explore numa conexão somente leitura. Quando você só quer resumos, standups ou busca, conecte aquele cliente no nível read. No Weft isso deixa só as 11 ferramentas somente leitura, e uma chamada recusada não conta na sua cota.
• Revise as chamadas destrutivas. Mantenha ligada a confirmação do seu cliente para ferramentas marcadas como destrutivas, em vez de aprová-las para a sessão inteira. No Weft elas são trash_task, archive_done_tasks e complete_sprint, e tarefas na lixeira continuam restauráveis por 30 dias.
• Trate o conteúdo do quadro como dado. Instruções na descrição de uma tarefa não são instruções suas. Coloque as regras que o seu agente segue no prompt de sistema ou nas regras do projeto, onde o texto de uma tarefa não consegue passar por cima delas.

O ciclo de claim também ajuda. Quando um agente chega a um passo irreversível, como publicar algo ou mexer em produção, ele pode chamar request_input e esperar a sua resposta, em vez de agir com base num texto que encontrou num cartão.

Quando você não precisa de um servidor MCP?

O MCP compensa o seu custo quando um modelo precisa escolher entre ações num quadro que muda o tempo todo. Muitos trabalhos não são assim.

• Um evento sempre gera uma atualização conhecida: um script contra a API do fornecedor é mais simples e mais barato do que um modelo.
• Você precisa de uma foto periódica: uma exportação resolve. O Weft oferece exportação em JSON e Markdown e um feed de calendário privado.
• Uma pessoa, uma sessão curta: um checklist em Markdown no repositório basta até o trabalho durar mais que o chat.
• O seu pipeline roda no CI sem cliente de IA: escolha uma ferramenta com CLI ou API REST. O Weft hoje não tem nenhuma das duas.

Como testar um servidor antes de se comprometer?

1. Conecte um cliente no nível read e peça um resumo do quadro. Nada deve mudar.
2. Mude para write num projeto de teste e peça para ele criar uma tarefa e movê-la. Confira se o quadro mostra qual cliente fez isso.
3. Comece a mesma tarefa a partir de dois clientes. O segundo deve ser recusado, e não duplicar o trabalho em silêncio.
4. Peça ao agente para fazer uma pergunta a você com opções e confira onde ela chega: no app, no celular, no e-mail.
5. Conclua a tarefa com um link como evidência, depois desconecte o cliente e confirme que a próxima chamada dele falha.

No Weft, o passo 1 é um comando no Claude Code, um clique no Cursor, uma linha de configuração mais codex mcp login weft no Codex ou adicionar o app no ChatGPT. O panorama completo de gerenciadores de tarefas com MCP está em gerenciadores de tarefas com MCP comparados (em inglês), e o ciclo de claim é explicado em o ciclo de claim.

Número de ferramentas não é sinal de qualidade?

Não. Uma lista longa de ferramentas custa contexto em toda sessão; as 32 ferramentas do Weft medem cerca de 17,7 mil tokens. O que importa é se as ferramentas de que você precisa existem, trazem indicações honestas de somente leitura e destrutiva e falham com erros claros.

OAuth é mesmo mais seguro que uma chave de API?

Ele elimina o segredo copiado e permite revogar um cliente isoladamente. O Weft emite refresh tokens, então o próprio cliente renova o login. Para clientes sem OAuth, o Weft também oferece tokens de acesso pessoal, mas eles não têm escopos.

Posso dar ao ChatGPT acesso somente leitura ao meu quadro do Weft?

Pode. Escolha o nível read na tela de consentimento ou mude depois nas Configurações, em Clientes de IA conectados. Essa conexão passa a ver só as 11 ferramentas somente leitura.

O que acontece se um agente travar enquanto segura uma tarefa?

No Weft, o lease vence depois de 20 minutos sem sinal de vida e a tarefa volta a ficar sem responsável, para que outro agente ou pessoa possa pegá-la.

Preciso de um plano pago para testar isso?

Não. O plano gratuito do Weft inclui 50 tarefas ativas e 200 chamadas MCP por mês, e o Pro custa R$ 39 por assento por mês ou R$ 329 por ano. Veja os preços.

Já usamos Linear ou Trello. Devemos trocar?

Não só por causa do MCP. Os servidores oficiais deles funcionam sobre os dados que o seu time já tem. Considere o Weft se você quer claim, perguntas e evidências dentro do próprio MCP; importar de CSV do Linear ou de JSON do Trello é grátis em todos os planos. Veja migrar do Linear ou migrar do Trello.