Utiliser le serveur MCP

Ce guide explique comment connecter un client MCP externe — Claude Code, un éditeur, le MCP Inspector — au serveur d’outils propre à Control Center.

Control Center enregistre 110 outils et les sert via le Model Context Protocol, en version de protocole 2024-11-05. Des familles entières d’outils que vous pourriez attendre sont absentes : il n’y a aucun outil de réunion ni de calendrier, et aucun outil de projet.

Trouver le point de terminaison

La surface MCP partage l’écouteur principal de cc_server. Il n’existe pas de port MCP distinct.

Point de terminaison	Méthode	Rôle
/mcp	POST	Transport HTTP streamable — c’est ce que parle un client
/mcp	DELETE	Terminer une session
/sse	GET	Flux de notifications envoyées par le serveur

Une installation locale par défaut se trouve donc à l’adresse http://127.0.0.1:9030/mcp.

1. Allez dans Paramètres → Serveur → Serveurs MCP
2. Lisez la carte Serveur MCP — elle indique s’il est en cours d’exécution ou arrêté, et le port sur lequel il écoute

La surface est active par défaut sur une installation neuve, si bien qu’un client loopback fonctionne sans avoir à toucher aux paramètres. Démarrer au lancement de l’app détermine s’il revient après un redémarrage ; Démarrer / Arrêter sont des commandes de session qui ne modifient pas cette préférence.

Le serveur se lie à loopback par défaut, de sorte que le point de terminaison n’est joignable que depuis la machine sur laquelle cc_server s’exécute, sauf si vous l’avez démarré avec --bind any.

Connecter un client

Pointez votre client vers le point de terminaison HTTP streamable. La forme exacte de la configuration regarde votre client ; l’URL est la même dans tous les cas.

{
  "mcpServers": {
    "control-center": {
      "type": "http",
      "url": "http://127.0.0.1:9030/mcp"
    }
  }
}

Claude Code

Claude Code ne récupérera pas cette configuration depuis un .mcp.json de projet — il place les serveurs MCP limités au projet derrière une demande d’approbation à laquelle un claude -p non interactif ne répond jamais. Passez la configuration explicitement :

claude --mcp-config /path/to/mcp.json --strict-mcp-config

--strict-mcp-config force Claude à n’utiliser que ce fichier, de sorte que le même serveur n’est pas aussi découvert depuis le projet et enregistré deux fois.

Point de contrôle : demandez au client de lister ses outils. Vous devriez voir des entrées mcp__* couvrant les tickets, les espaces, la mémoire, le graphe de code et la revue.

Servir MCP au-delà de l’hôte

1. Dans Paramètres → Serveur → Serveurs MCP, sur la ligne Jeton d’authentification, appuyez sur Définir et collez un jeton
2. Envoyez-le sous la forme Authorization: Bearer <token> à chaque requête POST /mcp

Une surface sans jeton refuse tout appelant non-loopback avec un code 403. C’est un refus par défaut, par conception : c’est le jeton qui rend possible, tout court, un service hors hôte.

Les changements de jeton s’appliquent immédiatement à la surface active — aucun redémarrage n’est nécessaire.

GET /sse accepte le jeton dans la chaîne de requête

Le flux de notifications est soumis à la vérification du jeton comme toute autre route, mais un EventSource de navigateur ne peut pas envoyer d’en-tête Authorization — /sse accepte donc aussi le jeton sous la forme ?token=<token>. Sans jeton, il répond 401.

Limiter chaque appel à un espace de travail

Chaque outil qui touche des données propres à un espace de travail exige workspace_id, et un appel sans cet identifiant est refusé plutôt que résolu vers un espace de travail « courant » :

{
  "workspace_id": "acme",
  "title": "Fix login bug",
  "priority": "high"
}

L’identifiant est celui qui figure dans l’URL de votre navigateur ou de l’application : /workspaces/<workspace_id>/…. Les seules exceptions sont les outils qui couvrent réellement plusieurs espaces de travail, comme list_workspaces et les outils du fil d’actualités — le fil d’actualités est propre à chaque utilisateur et un agent n’a pas d’utilisateur à lui, si bien que ces outils opèrent sur les fils du propriétaire du serveur.

Les outils limités à un dépôt vérifient en outre que le dépôt est lié à cet espace de travail.

Savoir ce que la surface refusera

• Filtrage par mode. Un appel est résolu côté serveur selon le mode de l’espace de l’agent appelant. Un agent en mode lecture seule ne peut pas atteindre un outil d’écriture en omettant space_id — le mode est alors recherché à partir de son exécution active.
• Garde-fous d’action. Les outils qui modifient l’état déclarent leurs classes d’effet et passent par la même politique que le reste du produit. Voir Configurer les garde-fous.
• Confirmation. Certains outils destructeurs construisent une charge utile de confirmation qui doit être approuvée avant que l’appel se poursuive.

Le catalogue complet est annoncé dans tools/list sans filtrage de découverte — un client MCP externe refuse d’appeler un outil qui n’est pas dans sa liste mise en cache, si bien que masquer des outils les casse plutôt que de les ranger.

Dépannage

Le client ne voit aucun outil

• Vérifiez que la carte Serveur MCP indique qu’il est en cours d’exécution
• Vérifiez que le port correspond à celui de votre cc_server
• Sur Claude Code, vérifiez que vous avez bien passé --mcp-config et --strict-mcp-config

403 depuis une machine qui n’est pas le serveur

Aucun jeton Bearer n’est configuré. Définissez-en un et envoyez-le.

Un appel d’outil échoue avec « Missing or invalid argument: workspace_id »

Ajoutez workspace_id. Il n’y a pas d’espace de travail implicite.

Un appel d’outil est refusé comme inconnu

Outils MCP répertorie le catalogue. Appelez le nom exactement tel qu’il y figure.

Guides connexes

• Outils MCP
• Configurer les garde-fous
• Exécuter un serveur sans interface

Concepts connexes

• Architecture