Serveur MCP

Tetikasa expose un serveur Model Context Protocol en transport HTTP (JSON-RPC 2.0, version de protocole 2025-06-18). Il implémente initialize, ping, tools/list et tools/call.

Pour la mise en place pas à pas, voir Brancher Claude ou Claude Code. Cette page est la référence.

URL

Une URL par organisation :

https://www.tetikasa.app/api/mcp/{organisation}

Vous la trouvez, prête à copier, dans Paramètres → Clés d'API, carte « URL du connecteur ». Un jeton OAuth identifie une personne, qui peut appartenir à plusieurs organisations : c'est l'URL qui lève l'ambiguïté. À chaque appel, le serveur vérifie que l'utilisateur est membre de cette organisation — s'il en est retiré, son accès cesse immédiatement.

https://www.tetikasa.app/api/mcp (sans organisation) reste accepté avec une clé d'API, qui porte déjà l'organisation.

Authentification

Deux modes coexistent ; le serveur accepte l'un ou l'autre sur chaque appel.

	OAuth	Clé d'API
Identifie	Une personne	Une organisation
Révocation	Individuelle	Coupe tous ceux qui l'utilisent
Expiration	Le client renouvelle seul	Aucune, sauf date fixée
Pour qui	Un connecteur, une équipe	Un script, une automatisation

OAuth 2.1 — découverte par RFC 9728 (/.well-known/oauth-protected-resource/api/mcp/{organisation}) et RFC 8414, enregistrement dynamique des clients (RFC 7591), PKCE S256 obligatoire, jetons de rafraîchissement. Les documents de métadonnées client (CIMD) ne sont pas pris en charge. Un écran de consentement est toujours présenté, une fois par client.

Clé d'API — la même que l'API v1, dans l'en-tête Authorization :

Authorization: Bearer tk_votreclé

Si votre client réserve cet en-tête, X-Api-Key avec la clé pour seule valeur est accepté. Voir Authentification.

Poignée de main sans authentification

initialize, ping et tools/list répondent sans jeton ni clé. C'est nécessaire : un client MCP vérifie la connexion avant que l'utilisateur ne fournisse quoi que ce soit, et un 401 à ce stade fait rejeter le connecteur. Ces méthodes n'exposent que le nom et la description des outils — aucune donnée.

Toute exécution d'outil (tools/call) exige un jeton ou une clé. Sinon : 401, avec un en-tête WWW-Authenticate portant resource_metadata — c'est ce qui indique à un client OAuth comment démarrer la connexion. Un jeton valide mais dont le porteur n'est pas membre de l'organisation de l'URL : 403.

Dans un connecteur Claude, les deux réglages d'authentification fonctionnent donc ; « Toujours requis » est recommandé, pour que la connexion soit demandée d'emblée plutôt qu'au premier outil.

Vérifier à la main

curl -X POST https://www.tetikasa.app/api/mcp/mon-agence \
  -H "Authorization: Bearer $TETIKASA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Outils

Outil	Rôle
list_members	Les membres de l'organisation, avec e-mail et rôle — pour savoir à qui assigner
list_clients	Liste les clients ; search pour vérifier qu'un client existe avant d'en créer un
create_client	Crée un client
list_projects	Liste les projets
get_project	Détail d'un projet, avec l'URL du portail
create_project	Crée un projet ; renvoie l'URL du portail à transmettre au client
list_tasks	Liste les tâches d'un projet, ou de toute l'organisation si project est omis (chaque tâche porte alors son projet et son client) ; filtres status, assignee (e-mail ou id d'un membre) et due_before (date ISO)
create_task	Crée une tâche ; audience: "client" la met à faire par le client, milestone_id la rattache à une étape, assignees (e-mails ou ids de membres) la confie à une ou plusieurs personnes
update_task	Modifie une tâche ; seuls les champs fournis changent ; status: "doing" la lance, "done" la termine, "canceled" l'annule ; assignees remplace la liste, [] retire tout le monde
list_milestones	Étapes du projet, avec leur position et next_milestone
create_milestone	Crée une étape à la suite des existantes
update_milestone	Modifie une étape ; status: "in_progress" la lance, "done" la termine
list_feedbacks	Les retours déposés par le client, avec le fil des réponses et le nom de chaque auteur
reply_to_feedback	Répond à un retour ; la réponse s'affiche dans le portail et part par e-mail au client
update_feedback_status	Change le statut d'un retour ; DONE prévient le client par e-mail
convert_feedback_to_task	Transforme un retour en tâche, comme le bouton de l'interface ; le lien entre les deux est conservé
link_feedback_to_task	Rattache un retour à une tâche existante du projet, ou l'en détache avec task: ""
list_task_comments	La discussion interne d'une tâche : les fils, leurs réponses, les fichiers joints, résolus ou non
add_task_comment	Écrit dans la discussion interne : un nouveau fil, ou une réponse avec reply_to ; mentions (e-mails ou ids de membres) les mentionne ; Markdown simple accepté
resolve_task_thread	Résout un fil de la discussion interne, ou le rouvre avec resolved: false
get_onboarding	Questions du questionnaire et réponses du client
add_onboarding_questions	Ajoute des questions à une étape, sans toucher au reste
update_onboarding_question	Reformule une question ; la réponse déjà saisie est conservée
remove_onboarding_question	Retire une question, et la réponse qui va avec
get_portal_settings	Les réglages du portail client : nom affiché, message, couleur, thème, vidéo d'accueil
update_portal_settings	Modifie ces réglages ; seuls les champs fournis changent
list_metrics	Les résultats d'un projet : chaque indicateur, sa valeur sur la période, la précédente et la variation
push_metrics	Envoie des chiffres (une valeur par jour et par indicateur) et définit les indicateurs ; la page Résultats du portail les affiche dans les 30 secondes
create_report	Prépare le rapport d'une période avec summary et next_steps ; brouillon par défaut, publish: true l'envoie au client par mail

Les statuts d'une étape sont pending, in_progress et done ; completed est accepté en entrée comme synonyme de done, et list_milestones rend un booléen done par étape pour éviter toute lecture des orthographes.

Les statuts d'une tâche sont backlog, todo, doing, done et canceled ; ceux d'une étape pending, in_progress et completed. Un changement de statut de tâche est inscrit dans son historique avec le nom de la personne, à condition que la connexion soit en OAuth : une clé d'API n'identifie personne, on préfère ne rien inscrire plutôt que d'attribuer le geste au hasard.

Les outils appellent les mêmes services que l'API v1 : mêmes contraintes, mêmes réponses. Les références de projet acceptent l'id ou le slug, pour qu'un assistant enchaîne create_project puis create_task sans manipuler d'identifiants opaques. Les tâches aussi : id ou slug. Les retours, les étapes et les messages de la discussion interne se désignent en revanche par leur id, obtenu avec list_feedbacks, list_milestones ou list_task_comments.

Quand la connexion se fait en OAuth, l'auteur d'une réponse à un retour — ou d'un message de la discussion interne — est la personne connectée, et c'est son nom qui s'affiche. Avec une clé d'API, qui n'identifie personne, la réponse est signée « Équipe » et le changement d'état d'une étape n'est pas inscrit dans son historique.

Limites

• Pas de suppression. Un assistant ne peut rien effacer.
• Mise à jour limitée aux tâches, aux étapes, au questionnaire, au portail, aux résultats et à la résolution des fils (update_task, update_milestone, update_onboarding_question, update_portal_settings, push_metrics, create_report, resolve_task_thread). Un message de la discussion interne ne se modifie que depuis l'interface, par son auteur. Projets et clients ne sont modifiables que depuis l'interface.
• La vidéo d'accueil s'active par un lien Loom, YouTube ou Vimeo. Un fichier vidéo se téléverse depuis la personnalisation du portail, pas depuis une conversation.
• Un assistant ne dépose pas de retour à la place du client : il peut les lire, y répondre, changer leur état et les convertir en tâche, rien de plus.
• Les questions d'onboarding s'ajoutent, ne se remplacent pas : les réponses déjà saisies par le client sont toujours préservées.
• Limite de débit pour les clés d'API, partagée avec l'API v1 : 120 requêtes par minute et par clé.
• Une organisation par URL. Pour en piloter plusieurs, ajoutez un connecteur par organisation.