Exemples d'utilisation de Kanera avec l'IA

Une fois qu'un agent IA est connecté à Kanera via MCP, il peut voir votre travail réel dans tous les domaines et agir en conséquence. C'est la différence entre un assistant qui devine à partir du texte collé et un assistant qui raisonne sur les données de l'espace de travail en direct : cartes, destinataires, dates d'échéance, étiquettes, champs personnalisés, notes, commentaires et activité.

Les exemples ci-dessous sont de véritables workflows. Chacun montre quoi demander, pourquoi l'agent peut le faire et ce que vous obtenez en retour. La plupart ne lisent que Kanera. Ceux qui le changent sont marqués (change Kanera) et avez besoin d'un accès en écriture : une connexion OAuth où vous êtes un éditeur sur le tableau, ou une clé API avec portée en écriture.

Suivre les bloqueurs et les transferts

Essayez ces invites avec un agent connecté :

• "Faites en sorte que le message final du produit bloque la copie de la page de destination. Associez la copie à la révision juridique facultative sans en faire une condition préalable."
• "Affichez les cartes bloquées dans l'espace de travail marketing et expliquez les bloqueurs et les propriétaires que je peux voir."
• "Regardez le tableau de lancement. Lorsqu'une carte est débloquée, lisez ses détails actuels et dites-moi qui peut la récupérer ensuite. "

Pour expliquer des chaînes entières, l'agent utilise cards.dependency_graph avec une seule carte, un tableau ou un espace de travail. Il peut également utiliser cards.set_relations, work.query_cards avec blockedOnly, et card.blocked / card.unblocked abonnements à des événements. Une course marquée bloquée est distincte de ces relations de carte. Voir Relations avec les cartes et blocage.

Examiner un calendrier et proposer un reprogrammation

"Consultez la chronologie du tableau de lancement. Quand la chaîne critique devrait-elle se terminer, qu'est-ce qui n'a pas de jeu et quelles cartes commencent avant la fin de leurs bloqueurs ? Montrez les dates et l'impact sur la journée de travail. Ne changez rien."

L'agent résout le tableau avec boards.list_accessible, puis appelle work.schedule avec exactement une seule portée :

{ "boardId": "<board UUID>" }

Utiliser { "workspaceId": "<workspace UUID>" } au lieu de planifier l'espace de travail ensemble. Ne réussissez pas les deux. Un calendrier de tableau suit les chaînes connectées accessibles vers d’autres tableaux. Le Guide chronologique explique la vision humaine du même calcul.

Lire summary.projectedFinish, summary.latestDue, et summary.slipDays pour la prévision et son retard par rapport à la dernière date promise. Par carte, plannedStart / plannedEnd décrire le plan stocké, earliestStart / earliestFinish tenir compte des prérequis, slackDays mesure la place pour glisser, critical marque le travail connecté sans jeu, et conflicts identifie les prérequis prévus pour se terminer trop tard. Les jours désignent les jours ouvrables du lundi au vendredi ; les cartes complétées sont exclues. Les cartes que la connexion ne peut pas ouvrir sont également exclues, décrivez donc la prévision comme le plan accessible.

Par exemple, si un prérequis se termine un vendredi et que son dépendant doit commencer ce vendredi-là, le premier transfert propre aura lieu le lundi : un jour ouvrable plus tard. cards.dependency_graph explique qui bloque qui ; utiliser work.schedule pour les dates réelles et le slack du planning.

"Proposez des dates pour que le MKT-42 commence lundi prochain et se termine vendredi. Expliquez quelles personnes à charge devraient déménager. Montrez la proposition avant de l'appliquer."

Il n'y a pas de paramètre d'entrée hypothétique sur work.schedule. Lisez le calendrier actuel, raisonnez à partir de ses durées et de ses liens, et étiquetez les impacts proposés comme des estimations. Ne modifiez pas les dates enregistrées simplement pour simuler une réponse. Lorsque l'utilisateur approuve un changement, relisez la carte avec cards.get, puis utilisez cards.update:

{
  "cardId": "MKT-42",
  "changes": {
    "startDateLocalDate": "2026-11-02",
    "dueDateLocalDate": "2026-11-06"
  }
}

Ces dates illustrent du lundi au vendredi ; résoudre des phrases relatives en utilisant la zone de l'utilisateur à partir de session.get et répétez les dates choisies. Les expressions de date de début sont également prises en charge. Lire work.schedule à nouveau après avoir enregistré pour signaler le résultat réel. Les dates des successeurs ne bougent pas automatiquement. L'application de cet exemple modifie Kanera et nécessite un accès en écriture.

Regarder la santé du calendrier

"Regardez le tableau de lancement. Dites-moi quand son premier conflit de planification apparaît, quand il se dissipe ou lorsqu'un changement de date du chemin critique repousse la fin prévue plus tard. Lisez le calendrier avant de créer un rapport, affichez les liens des cartes concernées et laissez les dates inchangées."

Un hôte compatible s'abonne séparément à schedule.conflict_detected, schedule.conflict_resolved, et schedule.critical_path_slipped, limité au tableau et à son espace de travail. Commencez par un work.schedule lire pour que les problèmes existants soient inclus ; les événements annoncent des changements après une ligne de base, pas une rediffusion. Lisez la planification à chaque occurrence, ignorez les propres écritures de la connexion, le cas échéant, et dupliquez les données répétées. eventId valeurs. Voir Abonnez-vous aux événements pour les charges utiles, l’actualisation et les limites de livraison.

Pour une révision matinale, demandez « mes conflits d'horaire, mon travail critique et mes cartes qui ont raté leur début prévu ». work.my_day les renvoie dans schedule.conflicts, schedule.critical, et schedule.lateToStart aux côtés de l’urgence et Up next. Pour une revue transversale du projet, work.portfolio_summary renvoie le cumul pris en charge avec par carte conflictCount, criticalCount, projectedFinish, latestDue, et slipDays; percer les cartes concernées avec work.schedule.

Si la chronologie ou les dépendances sont désactivées, l'agent signale TIMELINE_DISABLED ou DEPENDENCIES_DISABLED et demande à l'administrateur concerné d'activer la fonctionnalité si nécessaire. Il doit continuer avec le travail disponible plutôt que de réessayer l'opération refusée.

Mettez de l'ordre dans le travail d'aujourd'hui

"Affichez ma prochaine file d'attente, puis déplacez la carte de déblocage des paiements vers le haut et placez la révision de la documentation immédiatement après." (change Kanera)

L'agent lit d'abord les entrées classées actuelles, résout les cartes demandées et utilise les ancres d'entrée pour effectuer le mouvement exact. Il modifie le bon de travail sans modifier les dates d'échéance, les listes de flux de travail ou un champ personnalisé Priorité. Demandez-lui de montrer l'ordre proposé avant d'appliquer un remaniement plus large.

Planifiez le travail, puis suivez-le au fur et à mesure que le code arrive

Il s'agit du flux de travail qui montre ce que MCP débloque réellement : un agent de codage qui planifie dans Kanera, puis met à jour la même carte au fur et à mesure qu'il effectue le travail réel. Étant donné que l'éditeur de l'agent et Kanera sont tous deux accessibles via MCP, la carte de suivi reste précise d'elle-même : personne ne change d'onglet pour cocher des cases.

Étape 1 : planifiez la carte. Dirigez l'agent vers l'œuvre et demandez-lui d'enregistrer le plan là où l'équipe peut le voir :

"Lisez ce dépôt et la carte 'Mettre à niveau les dépendances'. Écrivez un plan de mise en œuvre dans la description de la carte et ajoutez une liste de contrôle avec un élément par projet qui doit être mis à jour." (change Kanera)

L'agent inspecte la base de code, rédige un plan, met à jour la description de la carte avec celui-ci et crée un élément de liste de contrôle par projet. Désormais, la carte est la source de vérité de l'effort, et non une conversation jetable.

Étape 2 : effectuez le travail et laissez l'agent clôturer sa propre liste de contrôle. Au cours de la même session (ou lors d'une session ultérieure), demandez à l'agent d'implémenter le changement dans tous les projets :

"Parcourez la liste de contrôle sur cette carte. Mettez à jour les dépendances dans chaque projet et, au fur et à mesure que chacun se construit et passe, marquez son élément de liste de contrôle comme terminé. (change Kanera)

Lorsque l'agent termine chaque projet, il coche l'élément correspondant sur la carte de suivi. Quiconque regarde le tableau constate de réels progrès en temps réel : la liste de contrôle se remplit au fur et à mesure que le code est réellement envoyé, et non lorsque quelqu'un se souvient de le mettre à jour. Chaque prélèvement est enregistré en tant qu'agent agissant pour vous, avec un via <agent> badge, de sorte que la carte sert également de piste d'audit de ce que l'agent a fait et quand.

Cette boucle « planifier dans la carte, puis signaler la progression sur la carte » fonctionne pour tout effort en plusieurs étapes : mises à niveau de dépendances, migrations, refactorisations ou fonctionnalité divisée en tâches.

Laissez le tableau montrer que l'agent travaille

Un travail de longue durée est invisible jusqu'à ce qu'il soit terminé, c'est ainsi que deux personnes finissent par faire le même travail. Un agent peut s'annoncer sur la carte à la place :

"Avant de commencer PLAT-42, ouvrez un agent exécuté dessus et tenez-le à jour au fur et à mesure. Marquez-le comme bloqué si vous avez besoin d'une décision de ma part. (change Kanera)

L'agent appelle runs.start avec un titre court, et la vignette de la carte affiche immédiatement une puce dynamique nommant l'agent et le travail. A partir de là runs.update est à la fois le rapport d'avancement et le battement de coeur :

1. runs.start — { cardId: "PLAT-42", title: "Implementing OAuth refresh", }. La puce apparaît sur la tuile et l'exécution en direct s'affiche sous la description de la carte.
2. Travaillez et continuez à faire des rapports. runs.update avec { runId, summary: "Refresh rotation done; wiring the retry path." }. Chaque appel est un battement de cœur, alors envoyez-en un au moins toutes les dix minutes pour un travail long, même vide.
3. runs.update avec status: "blocked" quand il a besoin de toi. La puce devient orange et le résumé indique ce qu'elle attend, la question est donc sur la carte plutôt que enterrée dans un journal de discussion.
4. runs.update avec status: "succeeded" (ou failed, ou cancelled) pour le fermer. La puce s'efface, la course reste dans l'historique de la carte et le résultat est enregistré dans le flux d'activité.

Demander runs.list d'abord lorsque plusieurs agents partagent un tableau : cela montre ce qui est déjà en vol donc deux d'entre eux ne démarrent pas la même carte. Si un agent plante en cours d'exécution, Kanera marque l'exécution au bout de quinze minutes plutôt que de laisser la carte occupée pour toujours.

Réagissez quand quelque chose change, sans qu'on vous le demande

Les invites ci-dessus s'exécutent lorsque vous les tapez. Un client qui accompagne Abonnements aux événements MCP, comme ChatGPT, peut également continuer à surveiller et agir dès qu'une carte est créée, modifiée, déplacée ou commentée, ou lorsque votre file d'attente Up next change. Kanera livre le changement au client ; le client exécute la tâche que vous avez décrite. Rien n'est configuré dans Kanera et la fin de la tâche met fin à l'abonnement.

Répondez aux questions sur une carte pendant votre absence.

"Regardez le tableau de lancement. Lorsqu'un nouveau commentaire pose une question, lisez la carte et son fil de discussion, et répondez avec la réponse si elle se trouve dans la carte ou dans les notes liées. Si ce n'est pas le cas, répondez que je ferai un suivi et dites-le-moi. (change Kanera)

Chaque nouveau commentaire arrive sous forme d'événement avec le texte du commentaire et la carte. L'agent lit le fil de discussion complet avec comments.list avant de répondre, il ne répond donc jamais à partir d'un résumé d'une seule ligne. Étant donné que chaque événement indique qui a effectué la modification et si l'agent lui-même l'a fait, une tâche comme celle-ci vérifie actor.self et saute ses propres réponses plutôt que de se répondre.

Gardez un canal de parties prenantes à jour.

"Dites-moi chaque fois qu'une carte passe dans la liste Terminé sur le tableau Mobile, avec un résumé en une ligne de ce qui a été expédié."

L'événement de déplacement contient la liste de destinations, afin que l'agent puisse filtrer Terminé et lire uniquement les cartes qui l'atteignent. Associez cela à une destination de discussion ou laissez le client publier le résumé là où vos parties prenantes le lisent.

Triez les nouveaux travaux au fur et à mesure qu’ils arrivent.

"Regardez la liste des admissions sur le tableau d'assistance. Pour chaque nouvelle carte, suggérez une étiquette de priorité et un propriétaire en fonction de la description et des anciennes cartes similaires, et laissez la suggestion sous forme de commentaire. Ne changez pas de carte." (change Kanera : le commentaire uniquement)

Un card.created l'événement se déclenche dès que la carte existe. L'agent le lit avec cards.get, recherche des cartes similaires et commente sa suggestion pour qu'une personne l'accepte. La décision reste humaine ; la recherche est effectuée avant que quiconque ouvre la carte.

Gardez une carte critique.

"Regardez PLAT-42. Si quelque chose change, y compris les commentaires, envoyez-moi une courte note indiquant ce qui a changé et qui l'a changé."

Abonnez-vous à une carte lorsqu'une carte de libération, de contrat ou d'incident ne doit pas changer tranquillement. L'événement nomme l'acteur, donc la note indique s'il s'agissait d'un coéquipier, d'un automate ou d'un autre agent.

Sachez quand vos priorités changent.

"Chaque fois que ma file d'attente Up next change parce que quelqu'un d'autre l'a réorganisée, dites-moi ce qui a bougé et ce qui est maintenant en haut."

Un priorities.changed L'événement se déclenche lorsque votre file d'attente gagne, perd ou réorganise une entrée, y compris lorsqu'une carte en file d'attente est complétée ou réaffectée. Il ne transporte aucune carte, donc l'agent lit la file d'attente avec priorities.list, le compare à l'ordre qu'il a vu la dernière fois et ignore les modifications là où actor.self est vrai ou actor.userId c'est toi. Seule votre propre file d'attente peut être surveillée.

Obtenez un briefing le matin.

"Chaque matin de la semaine, dites-moi ce qui est en retard, ce qui est dû cette semaine et ce qui est en tête de ma file d'attente Up next."

Un my_day.ready l'événement arrive à 08h00 en semaine dans votre fuseau horaire, pendant que votre e-mail de résumé quotidien est activé. L'agent y répond par un work.my_day appel, qui renvoie les cartes en retard, à payer cette semaine, la liste de contrôle en retard et les cartes attribuées inactives ainsi que le chef de votre file d'attente Up next.

Deux habitudes fiabilisent ces tâches : demander à l'agent de lire la carte avant d'écrire, puisque les événements sont des résumés, et pour utiliser les clés d'idempotence pour les écritures répétables, puisque le même changement peut arriver plusieurs fois. La livraison se fait au mieux en quelques minutes ; si le client est inaccessible pendant plus longtemps, la tâche doit être récupérée en lisant l'état actuel au lieu d'attendre une relecture.

Triage matinal en une seule invite

"Montrez-moi tout ce qui m'est assigné dans l'espace de travail, regroupé par urgence. Signalez tout ce qui est en retard, tout ce qui n'a pas de date d'échéance et tout ce qui n'a pas bougé depuis une semaine."

Pour un démarrage rapide, work.my_day renvoie les travaux en retard, à échéance cette semaine, les listes de contrôle en retard et les travaux inactifs ainsi que votre file d'attente suivante en un seul appel. Pour les regroupements personnalisés, la requête de travail limitée extrait simultanément l’intégralité de la file d’attente de votre espace de travail. Il peut filtrer par date d'échéance, état de retard, inactivité et dernier mouvement, puis faire apparaître les deux ou trois éléments dont vous avez besoin aujourd'hui. Dans l'application, Home et My Cards fournissent les versions humaines de ce flux de travail.

Mise à jour instantanée

"Préparez mon standup : ce que j'ai fermé hier, ce sur quoi je travaille aujourd'hui et tout ce qui est bloqué."

L'agent lit l'activité récente et les cartes qui vous sont attribuées, puis rédige une mise à jour précise. Collez-le dans Slack ou lisez-le. L'intégré prepare_standup_update prompt fait exactement cela si votre client fait apparaître des invites.

Examen du tableau pour un manager

"Résumez le tableau de la feuille de route. Appelez les bloqueurs, les cartes périmées, les cartes sans propriétaire et ce qui est susceptible de faire échouer ce sprint."

Un agent disposant d'un accès en lecture au tableau peut combiner les métadonnées du tableau, les pages de cartes limitées, les filtres de travail obsolète et les historiques de cartes sélectionnés pour examiner un tableau comme le ferait un prospect - pas seulement en répertoriant les cartes, mais en raisonnant sur les risques. Idéal avant une réunion de planification.

Transformez une réunion en cartes

"Voici mes notes de l'appel client. Rédigez des cartes pour chaque élément d'action avec un titre, une description Markdown et une liste suggérée. Montrez-moi d'abord les brouillons - ne créez rien pour l'instant."

L'agent propose des cartes structurées. Vous révisez, modifiez, puis dites :

"Créez-les dans la liste d'admission et étiquetez-les customer-request." (change Kanera)

Ce modèle « rédiger, réviser, appliquer » est le moyen le plus sûr de laisser un agent créer du travail : vous voyez toujours le plan avant que quoi que ce soit n'arrive à Kanera.

Une fois que vous avez approuvé, l'agent crée l'ensemble du plan en un seul appel, avec les étiquettes, les destinataires et la date d'échéance de chaque carte déjà définis, et il vérifie d'abord chaque carte afin qu'un mauvais nom d'étiquette ou un mauvais coéquipier arrête le lot avant que quoi que ce soit n'arrive. Les cartes créées par votre agent sont automatiquement surveillées par vous, de sorte que les réponses qui y figurent parviennent à vos notifications, marquées via <agent>.

Récupérez les réponses pendant que l'agent travaille

"Publiez le plan de migration sur DEV-938, demandez à @Priya de se déconnecter et continuez à vérifier sa réponse pendant que vous commencez les tests." (change Kanera)

L'agent mentionne Priya dans son commentaire, qui la prévient par boîte de réception, e-mail et push. Un agent exécuté sur votre machine n'a pas d'adresse que Kanera peut rappeler, il vérifie donc vos notifications toutes les quelques minutes avec notifications.list, ne voyant que ce qui est nouveau depuis la dernière fois qu'il a été consulté et aucun de ses propres écrits. Lorsque Priya répond, elle lit le commentaire et continue.

Capturez un rappel sans choisir de tableau

"Rappelez-moi de renouveler l'assurance du lieu la semaine prochaine." (change Kanera)

Lorsque vous ne nommez aucun tableau, l'agent ajoute l'élément en tant que tâche ouverte sur le Boîte de réception page de votre privé Bloc-notes au lieu de demander où il doit aller. Plus tard, demandez « qu'y a-t-il dans ma boîte de réception ? pour le relire, ou "cocher celui de l'assurance" pour le vérifier. Nommez un tableau lorsque l'élément appartient à l'équipe et l'agent y crée une carte à la place.

Les dates fonctionnent comme vous les dites. "Rendre MKT-42 dû demain à 13 heures" définit demain dans votre propre fuseau horaire avec le créneau d'échéance de l'après-midi, et l'agent vous indique la date utilisée.

Revenez sur une carte au bon moment

"Rappelez-moi le MKT-42 vendredi à 15 heures." (change Kanera)

Lorsque vous nommez une carte qui existe déjà, l'agent définit un rappel dessus au lieu de créer une tâche. Il vous indique l'heure exacte à laquelle le problème a été résolu, dans votre propre fuseau horaire, et Kanera vous avertit une fois à l'échéance, via les canaux que vous avez choisis. Vos rappels de carte. Les rappels arrivent jusqu'à huit semaines à l'avance. Demandez : « Quels rappels ai-je ? » pour les lister, ou "effacer mon rappel sur MKT-42" pour en supprimer un. "Watch MKT-42" suit plutôt l'activité de la carte.

Joindre des preuves d'une session de codage

"Joignez la capture d'écran de la page de connexion ayant échoué et le journal de test au DEV-938, puis résumez ce que le journal indique comme ayant échoué." (change Kanera)

Un agent travaillant sur votre machine reçoit un lien de téléchargement unique pour chaque fichier et le télécharge avec curl, donc les captures d'écran et les longs journaux ne transitent jamais par le chat. Il peut ensuite relire le journal de la carte avec cards.get_attachment, et regardez les captures d'écran des autres pièces jointes pour répondre aux questions à leur sujet.

Recherche transversale qui comprend le contexte

"Trouvez chaque carte, note ou commentaire mentionnant la migration des paiements et dites-moi lesquels sont encore ouverts."

La recherche MCP couvre les cartes, les notes, les commentaires et les noms de fichiers de pièces jointes dans l'espace de travail. L'agent ne se contente pas de renvoyer les correspondances : il les regroupe, vous indique ce qui est fait par rapport à ce qui est ouvert et vous oriente vers les fils de discussion importants.

Nettoyage et hygiène

"Répertoriez les cartes attribuées dans cet espace de travail sans date d'échéance ni étiquette, et suggérez une étiquette de priorité et une date d'échéance réaliste pour chacune en fonction de la description." (les suggestions sont en lecture seule ; leur application change Kanera)

L'agent propose des métadonnées afin que votre tableau reste déclarable. Approuvez le lot et il peut définir des étiquettes, des dates d'échéance et des valeurs de champs personnalisés en un seul passage.

Gardez une carte à jour d'une discussion extérieure

"Ajoutez un commentaire à la carte 'Déploiement SSO' résumant ce fil de discussion et déplacez-le vers En cours." (change Kanera)

L'agent rédige un commentaire récapitulatif concis et met à jour la liste des cartes, de sorte que le tableau reflète la réalité sans que personne ne retape le statut à la main. Chaque changement entraîne un via <agent> badge dans l'activité de la carte, afin qu'elle reste auditable.

Si vous connaissez la clé de la carte, utilisez-la directement : "Ajouter ce récapitulatif à PLAT-42 et marquez-le comme complet." Les clés actuelles, les clés historiques exactes et les liens canoniques de carte Kanera peuvent tous être utilisés comme références de carte MCP. Un lien canonique lève l'ambiguïté dans le cas rare où la même clé est visible dans plusieurs organisations.

Divisez une liste chargée en sections

"Dans la liste Backlog du tableau Roadmap, ajoutez des séparateurs bleus intitulés 'Prochaine version' et 'Plus tard'. Mettez 'Prochaine version' avant PLAT-42, placez 'Plus tard' après le séparateur de recherche existant, puis déplacez PLAT-57 immédiatement en dessous de 'Prochaine version'." (change Kanera)

L'agent lit les cartes et les séparateurs actuels du tableau, résout les ancres demandées et crée ou déplace chaque séparateur de première classe à une position exacte. Les cartes et les séparateurs partagent une seule voie de classement, de sorte que l'agent peut également positionner une carte par rapport à un séparateur. Les séparateurs restent spécifiques au tableau même lorsque la liste des flux de travail est partagée avec d'autres tableaux.

Équilibrage de la charge de travail au sein d'une équipe

"Dans cet espace de travail, affichez le travail assigné à chaque personne. Qui est surchargé, qui a de la place et quelles cartes pourraient raisonnablement bouger ?"

La requête de travail d'équipe limitée renvoie le travail visible attribué, non attribué, en retard et obsolète dans la portée sélectionnée. L'agent peut raisonner sur la charge de toute l'équipe et proposer un rééquilibrage, puis, avec votre approbation, réaffecter des cartes spécifiques. (réaffectation des modifications Kanera)

Cumuls croisés pour un agent

"Donnez-moi un récapitulatif des livraisons pour cette organisation. Affichez les travaux actifs, en retard, à venir, non attribués et récemment terminés par espace de travail et tableau, puis signalez les domaines qui nécessitent une attention."

work.portfolio_summary renvoie directement les regroupements d'organisation, d'espace de travail et de tableau délimités. L'agent lit d'abord les agrégats, puis inspecte uniquement les tableaux ou cartes nécessitant des détails à l'appui. Le rollup est disponible via MCP, l'API publique, kanera portfolio, et kanera.work.portfolio() dans le SDK. Il ne nécessite pas de page Web Portfolio.

Brouillon d'une note que vous avez déjà écrite

« Transformez ma note « Réorganisation de l'intégration au troisième trimestre » en une carte avec un titre clair et une description Markdown qui présente les étapes sous forme de liste de contrôle. »

Le draft_card_from_notes L'invite transforme la réflexion libre d'une note Kanera en un travail structuré et réalisable.

Conseils pour en tirer le meilleur parti

• Gardez les informations d'identification sans surveillance étroites. Utilisez un Lire Clé API ou connexion au service pour le tri, les résumés et la recherche lorsque l'automatisation ne doit jamais apporter de modifications. Personal OAuth est compatible en lecture/écriture, configurez donc plutôt les autorisations et les confirmations des outils dans le client MCP.
• Demandez d'abord un plan. Pour tout ce qui modifie Kanera, demandez des ébauches ou une proposition de plan, examinez-le, puis dites « appliquez-le ».
• Soyez précis sur la portée. Nommez le tableau, la liste, l'espace de travail ou la personne afin que l'agent cible les bonnes données.
• Laissez-le fonctionner dans tous les domaines. Les plus grands gains proviennent de questions auxquelles une vue unique ne peut pas répondre : charge de travail, recherche inter-projets et état de livraison inter-projets.

Pour la configuration, les clés API, les étendues et la liste complète des ressources et des actions que l'agent peut utiliser, voir Connectez Kanera à votre agent IA, le référence technique, et le inventaire des outils.