MCP (Model Context Protocol)

Avant un tel standard, chaque application qui voulait donner à un modèle l’accès à un agenda, une base de données ou un dépôt de code devait écrire son propre connecteur. MCP partage le travail en deux. Un serveur enveloppe une capacité, comme un système de fichiers ou un suivi de tickets, et décrit ce qu’il propose. Un client, dans l’application d’IA, découvre cette description et la transmet au modèle, qui peut alors appeler ces capacités. Les serveurs peuvent offrir des outils qui exécutent des actions, des ressources qui fournissent des données à lire et des prompts qui regroupent des consignes toutes faites. Les serveurs typiques relient un agenda, une application de notes, un suivi de bogues, un tableur, une base de données, une boîte mail, un dépôt de code ou un navigateur, chacun exposé de la même façon prévisible. Les ressources peuvent être des fichiers, des lignes de tables, des captures d’écran ou des journaux ; les prompts, des modèles comme une liste de relecture de code ou un résumé de réunion.

Les serveurs tournent soit sur ta machine, en dialoguant avec l’application par l’entrée et la sortie standard, soit à distance en HTTP. C’est une couche différente de l’appel d’outils. L’appel d’outils est la manière dont un modèle demande une fonction dans une requête ; MCP est la manière dont l’application trouve et atteint ces fonctions, nombreuses, au départ. L’application traduit d’ordinaire les outils MCP découverts en définitions d’outils ordinaires pour le modèle : les deux se complètent, et le modèle ne se connecte jamais directement à un serveur. Les serveurs distants soulèvent aussi la question de l’authentification : renseigne-toi sur la manière dont un serveur prouve qui l’appelle et sur le lieu où atterrissent tes identifiants.

Cette commodité apporte des risques qui méritent attention. Un serveur peut lire et modifier tout ce à quoi tu lui donnes accès, et un serveur malveillant ou négligent peut faire fuiter des données ou lancer des actions nuisibles. Les descriptions et résultats venus d’un serveur sont du texte que le modèle va lire : ils peuvent cacher des instructions destinées à l’orienter. Installe des serveurs de sources fiables, accorde les droits les plus étroits, vérifie ce que fait chaque outil et préfère une demande de confirmation pour tout ce qui écrit, envoie ou supprime. Une bonne habitude consiste à lire la liste des outils qu’annonce un serveur avant de l’activer, comme tu lirais les autorisations d’une appli mobile.

Pour être précis sur ce qui existe aujourd’hui : Dans les Missions, NeverNo peut se connecter à un serveur MCP distant que tu ajoutes toi-même (son adresse et un jeton facultatif), tandis que l’API n’héberge pas de serveurs MCP et ne s’y connecte pas elle-même. Il propose l’appel de fonctions sur les complétions de discussion, où ton propre code définit les outils et les exécute, ainsi qu’un point d’accès Messages compatible Anthropic. Les modèles dont capabilities.tools vaut true dans la liste /models acceptent des outils.

Un outil que tu fais tourner toi-même et qui parle MCP peut tout de même utiliser NeverNo comme modèle en pointant son adresse de base vers https://neverno.ai/api/v1, puisque les points d’accès suivent les formats d’OpenAI et d’Anthropic. Les connexions MCP vivent alors dans cet outil, pas chez NeverNo. DeepSeek V4 Flash, un modèle privé et gratuit à fenêtre de contexte de 128 000 jetons, figure dans la liste.