Taskavel MCP agit toujours comme un utilisateur Taskavel authentifié. Il ne crée pas un administrateur IA à l’échelle de l’espace de travail et ne combine pas silencieusement l’accès d’autres comptes. Le client peut travailler seulement avec les projets dont son utilisateur connecté est propriétaire ou membre, et les mêmes vérifications de rôle qui protègent l’application web protègent les appels d’outils MCP.
Ce modèle est important dans un espace de travail partagé. Donner à un assistant une connexion MCP ne lui donne pas l’autorisation de lire chaque projet de l’organisation. Inversement, un projet absent d’une réponse d’outil est généralement un problème d’appartenance ou de compte, non une fonctionnalité MCP manquante.
Les rôles continuent de s’appliquer
Les propriétaires et administrateurs peuvent effectuer des actions administratives comme inviter ou retirer des membres. Propriétaires, administrateurs et membres peuvent créer et mettre à jour le travail normal, y compris tâches et commentaires. Les invités peuvent lire le contenu du projet et observer les tâches, mais ne peuvent ni commenter, ni téléverser de pièces jointes, ni modifier les tâches.
Demandez au client de signaler un refus plutôt que de réessayer à répétition un outil d’écriture. Si une action est refusée, confirmez le compte connecté et le rôle dans Taskavel. Ne contournez pas une restriction de rôle en empruntant le PAT ou la connexion OAuth d’une autre personne. Le propriétaire approprié de l’espace de travail doit ajuster l’appartenance lorsque l’accès élargi est intentionnel.
Résoudre la cible avant mutation
De nombreux outils Taskavel acceptent un nom de projet ou un identifiant de projet exact. Un nom lisible est pratique mais peut être ambigu. Pour tout changement important, demandez au client de lister les projets ou afficher les candidats correspondants, puis utilisez l’identifiant retourné si nécessaire. Le même principe s’applique aux colonnes, jalons, étiquettes et tâches.
Une demande explicite est plus sûre et plus facile à auditer : « Dans le projet Website, déplace la tâche #42 vers Review » indique un projet, une tâche et un résultat. Une demande vague comme « nettoie le backlog » force le client à deviner les limites et doit être précisée avant d’agir.
Classifications d’outils et suppression
La référence d’outils MCP générée marque chaque action comme lecture, écriture ou destructive. Utilisez les outils de lecture pour établir le contexte avant une écriture. Traitez les actions destructives comme un point d’approbation distinct. En particulier, la suppression définitive ne s’applique qu’après archivage de la tâche et exige une confirmation explicite. Archiver d’abord vous donne l’occasion d’examiner avant toute étape irréversible.
Lisez approbations sûres pour les garde-fous opérationnels et dépannage lorsqu’un résultat manque ou est refusé.