MCP

Permissões MCP e âmbito do projeto

Compreenda como o utilizador Taskavel ligado, a associação ao projeto e as funções limitam o acesso MCP.

O MCP do Taskavel atua sempre como um utilizador Taskavel autenticado. Não cria um administrador de IA para todo o espaço de trabalho nem combina silenciosamente o acesso de outras contas. O cliente apenas pode trabalhar com projetos pertencentes ao utilizador ligado ou dos quais este seja membro, e as mesmas verificações de função que protegem a aplicação Web protegem as chamadas das ferramentas MCP.

Este modelo é importante quando partilha um espaço de trabalho. Conceder uma ligação MCP a um assistente não lhe dá permissão para ler todos os projetos da organização. Da mesma forma, quando um projeto não aparece na resposta de uma ferramenta, trata-se normalmente de um problema de associação ou de conta, não de uma funcionalidade MCP em falta.

As funções continuam a aplicar-se

Os proprietários e administradores podem efetuar ações administrativas no projeto, como convidar ou remover membros. Os proprietários, administradores e membros podem criar e atualizar trabalho normal, incluindo tarefas e comentários. Os convidados podem ler o conteúdo e acompanhar tarefas, mas não podem comentar, carregar anexos nem alterar tarefas.

Peça ao cliente que apresente uma recusa em vez de tentar repetidamente uma ferramenta de escrita. Se uma ação for recusada, confirme no Taskavel a conta e a função ligadas. Não contorne uma restrição de função utilizando o PAT ou a ligação OAuth de outra pessoa. O proprietário adequado do espaço de trabalho deve ajustar a associação quando se pretender um acesso mais abrangente.

Resolva o destino antes de alterar

Muitas ferramentas do Taskavel aceitam um nome de projeto ou um ID exato. Um nome legível é conveniente, mas pode ser ambíguo. Para qualquer alteração substancial, peça primeiro ao cliente que liste os projetos ou apresente as correspondências e utilize depois o ID devolvido, se necessário. O mesmo princípio aplica-se a colunas, marcos, etiquetas e tarefas.

Um pedido explícito é mais seguro e fácil de auditar: «No projeto Website, move a tarefa n.º 42 para Revisão» indica o projeto, a tarefa e o resultado. Um pedido vago, como «arruma o backlog», obriga o cliente a adivinhar limites e deve ser restringido antes de agir.

Classificações das ferramentas e eliminação

A referência MCP gerada classifica cada ação como leitura, escrita ou destrutiva. Utilize ferramentas de leitura para estabelecer o contexto antes de pedir uma escrita. Trate as ações destrutivas como um ponto de aprovação separado. Em particular, a eliminação permanente só se aplica depois de uma tarefa já estar arquivada e a chamada incluir confirmação explícita. Arquivar primeiro permite rever antes de qualquer passo irreversível.

Leia aprovações seguras para conhecer as proteções operacionais e a resolução de problemas quando um resultado estiver em falta ou for recusado.

Last reviewed 26 de jul. de 2026