Outils et serveurs MCP

Connectez Rikoo à vos systèmes via le Model Context Protocol, authentifié par un secret du coffre ou par OAuth 2.1, et restreint outil par outil.

Les outils font passer un agent de quelque chose qui répond à quelque chose qui agit. Rikoo parle le Model Context Protocol : un serveur MCP joignable en HTTP, le vôtre ou celui d'un éditeur, se déclare une fois dans un projet puis s'accorde aux agents qui en ont besoin.

Déclarer un serveur

Sur l'écran MCP Servers, Ajouter un serveur demande son adresse, son transport et son authentification, et Parcourir la bibliothèque part d'une liste de serveurs connus. Tester la connexion interroge le serveur et remplit la liste des outils qu'il expose. Cette liste n'est rafraîchie qu'à votre demande, et chaque découverte consigne ce qui a été ajouté, retiré ou modifié depuis la précédente.

Transport	Quand l'utiliser
Streamable HTTP	Le défaut, et le transport de la spécification MCP actuelle (point d'accès /mcp).
SSE legacy	Un serveur qui suit encore la spécification du 2024-11-05 (point d'accès /sse).
JSON-RPC nu	Un serveur tolérant qui répond en JSON-RPC sans la poignée de main MCP.

Un serveur stdio tiers ne peut pas être déclaré : l'exécuter reviendrait à laisser le worker lancer un binaire fourni par un locataire.

Les serveurs déclarés, leur transport et leur état de connexion. Chacun s'accorde à un agent, et l'accès peut être restreint outil par outil.

Authentification

Méthode	Comment ça marche	Quand l'utiliser
Aucune	Aucun identifiant n'est envoyé	Un serveur de votre réseau qui n'authentifie pas ses appelants
Secret du coffre	Un jeton porteur ou une clé d'API rangé dans le coffre de secrets et joint à chaque appel	Un serveur interne, ou un éditeur qui émet des jetons de longue durée
OAuth 2.1	Code d'autorisation avec PKCE (S256 uniquement), ou identifiants client quand le serveur les propose. Les jetons sont scellés avec la même enveloppe que le coffre, conservés avec le serveur et rafraîchis automatiquement	Les serveurs hébergés qui n'acceptent qu'OAuth, comme Notion, Linear ou GitHub

Pour OAuth, Rikoo découvre le serveur d'autorisation à partir des métadonnées que publie le serveur MCP et enregistre un client automatiquement, sauf si vous saisissez un client_id préenregistré. C'est le worker qui échange le code contre des jetons, jamais le serveur d'API.

Restreindre les outils

Deux niveaux restreignent ce qui peut s'exécuter :

• Sur le serveur, pour tout le projet. Les outils cochés sur la page du serveur forment le plafond du projet. Tous cochés, il n'y a aucune restriction, y compris pour les outils découverts plus tard.
• Sur l'accès de l'agent. Décocher un outil l'interdit à cet agent. Dès qu'un outil est décoché, l'accès porte une liste explicite : un outil que l'éditeur ajoute plus tard reste bloqué pour cet agent tant que personne ne l'autorise.

Un accès sans restriction donne à l'agent tous les outils que le projet autorise sur ce serveur.

Dans l'édition Enterprise, un outil peut en plus être configuré pour exiger une validation humaine : l'exécution attend la décision avant que rien ne parte. Voir Licence Enterprise.

L'exposition n'est pas une frontière

Cacher un outil au modèle est un choix d'ergonomie, pas un contrôle de sécurité. Le worker vérifie de nouveau la restriction de l'agent au moment où il ouvre l'appel : un modèle qui invente le nom d'un outil qui ne lui a pas été accordé reçoit un refus, pas une exécution.

Santé et sorties volumineuses

Chaque serveur a une Sonde de santé, dont la cadence se règle par serveur ou se désactive, et le Studio affiche son dernier contact réussi. Après 3 échecs consécutifs, un disjoncteur cesse d'appeler le serveur pendant 1 minute, puis plus longtemps (jusqu'à 10 minutes) s'il reste en panne : un serveur mort ne coûte pas un délai d'attente à chaque appel. Les délais d'appel et de connexion se règlent par serveur.

Une sortie d'outil volumineuse ne remplit pas le contexte du modèle. Au-delà d'un seuil de taille, la sortie complète part dans le stockage objet, et le modèle reçoit un aperçu avec la référence qui lui permet de lire la suite (read_tool_result).

Images et autres médias

Certains serveurs renvoient des images ou du son : une capture d'écran, un graphique, un enregistrement. Par défaut, ces fichiers ne sont ni stockés ni affichés. L'interrupteur Autoriser les médias (images, audio) de ce serveur se règle sur l'accès de l'agent, serveur par serveur. Une fois activé, chaque fichier passe par la même politique d'admission qu'une pièce jointe (type vérifié sur les octets, limites de taille), est stocké et s'affiche dans les conversations de l'agent. Le modèle ne reçoit jamais le fichier lui-même, seulement une référence. Le réglage est figé à la création d'une exécution.

Les serveurs embarqués

Chaque projet est livré avec 2 serveurs qui ne demandent ni installation ni adresse :

• Espace de travail : lister, lire (page par page) et écrire des fichiers, exécuter du Python (run_python) ou une commande (run_command). Il n'a aucun accès réseau.
• Navigateur : naviguer, lire une page, remplir un formulaire. Son trafic sort par un mandataire d'egress dédié, qui applique la même garde anti-SSRF que le reste de la plateforme.

Ils sont éteints par défaut. Un agent les obtient par un accès, comme n'importe quel serveur MCP, et les restrictions d'outils, le disjoncteur, la sonde de santé et la trace s'y appliquent sans changement.

L'espace de travail appartient à la conversation, pas à une seule exécution. Les fichiers joints par l'utilisateur apparaissent sous uploads/, que l'agent peut lire mais pas modifier ; l'agent travaille dans work/ et dépose dans outputs/ ce qu'il rend à l'utilisateur. Ce qu'il écrit dans l'un et l'autre est enregistré dans le stockage objet comme pièces jointes de la conversation, à la fin de chaque exécution. Chaque espace de travail tourne sous son propre utilisateur non privilégié, dans un répertoire qu'aucune autre conversation ne peut lire, avec des limites de temps, de disque et de processus.

L'espace de travail exige aussi un utilisateur identifié par la surface d'où vient le message : un visiteur anonyme du widget ne l'obtient jamais. Sur le widget, il est fermé par défaut, et l'exploitant l'ouvre sciemment en passant WORKSPACE_SURFACE_WIDGET à true. Sur l'API, Slack et le Studio, il est ouvert.

Rien de ce que renvoie un outil n'est fiable

Une page web, un fichier, la réponse d'API d'un éditeur : rien de tout cela n'est une instruction. La sortie des outils HTTP, MCP et de recherche de connaissances, ainsi que les descriptions des outils MCP tiers, sont encadrées comme données non fiables avant d'atteindre le modèle, en un seul endroit pour toute la plateforme. L'encadrement réduit le risque d'injection indirecte de prompt sans le supprimer : c'est pourquoi un agent servi au public perd ses capacités les plus risquées (voir Guardrails).