Qu'est-ce qu'un serveur ERP MCP ?

Un serveur qui transforme un système en outils

Le Protocole de Contexte de Modèle a trois rôles. Un hôte est une application IA telle que Claude ou ChatGPT. À l'intérieur de l'hôte, un client est créé par serveur et ne communique qu'avec ce serveur. Un serveur est un service qui offre un contexte et des capacités à l'hôte à travers un petit nombre de primitives. Les principes de conception de la spécification stipulent que les serveurs doivent être faciles à construire, composables et incapables de voir l'ensemble de la conversation ou d'autres serveurs ; l'hôte conserve la conversation et impose le consentement, le serveur ne voit que les appels qui lui sont adressés.

Un serveur ERP MCP n'est donc pas l'ERP. C'est la surface d'action de l'ERP, exprimée sous forme d'outils avec des entrées typées, servies à une URL. La décision de conception intéressante est ce qu'est un outil. Un serveur météo en a un ; un système d'entreprise en a des centaines, et les utiles sont des actions qu'une personne pourrait entreprendre (créer une facture, enregistrer un paiement, déplacer un accord, réserver des stocks) plutôt que des lignes dans des tableaux. Le serveur d'espace de travail de Sois, par exemple, publie des outils avec des noms tels que Créer une facture, enregistrerPaiement, searchContacts et examinerContact regroupés par module, et la liste exacte qu'un appelant reçoit dépend de son identité.

Outils, ressources et invites

La spécification définit trois primitives de serveur, et elles diffèrent par qui contrôle leur utilisation. Les outils sont contrôlés par le modèle : le modèle décide quand en appeler un. Les ressources sont pilotées par l'application : l'hôte décide quel contexte attacher, souvent avec l'utilisateur choisissant dans une liste. Les invites sont des modèles contrôlés par l'utilisateur. Un ERP a besoin de la première, peut bénéficier de la seconde, et a rarement besoin de la troisième.

Deux caractéristiques des résultats des outils sont importantes pour un système d'entreprise. Un outil peut déclarer un schéma de sortie et renvoyer contenu structuré qui y correspond, ainsi que le texte qu'un modèle lit, afin qu'une intégration puisse utiliser le résultat sans analyser de la prose. Et un outil qui échoue pour une raison commerciale (une facture dans un état incorrect, une date dans le passé, une autorisation manquante) renvoie un résultat normal avec isError: true et une explication, plutôt qu'une erreur de protocole, afin que le modèle puisse corriger son entrée et réessayer. Les erreurs de protocole sont réservées aux demandes mal formées et aux outils inconnus.

Le transport et la spécification actuelle

Deux transports sont standards. Stdio est pour un serveur que le client lance en tant que processus local, ce qui est le fonctionnement des outils de bureau tels que l'accès aux fichiers. HTTP streamable est pour les serveurs distants et est ce qu'un ERP utilise : le serveur expose un point de terminaison qui accepte un POST HTTP par message JSON-RPC et répond soit avec un objet JSON, soit avec un flux d'événements envoyés par le serveur (SSE) limité à cette demande, de sorte qu'un appel long puisse envoyer des progrès avant son résultat final. L'ancien transport HTTP avec SSE est obsolète.

La révision actuelle, 2026-07-28, a modifié le transport d'une manière qui compte pour quiconque déployant un serveur derrière un équilibreur de charge. Elle a supprimé les sessions au niveau du protocole : il n'y a plus de poignée de main d'initialisation ni d'en-tête d'identifiant de session, chaque demande porte sa version de protocole et ses capacités client dans ses propres métadonnées, et un serveur qui a besoin d'état entre les appels renvoie un handle explicite que le modèle renvoie en tant qu'argument. Les serveurs écrits contre la révision 2025-11-25, qui utilisaient des sessions, continuent de fonctionner car les clients sont tenus de détecter l'ancienne ère et de revenir en arrière ; un nouveau serveur ne devrait pas adopter de sessions.

Autorisation : pour qui l'appel est destiné

Pour les transports HTTP, la spécification définit un flux OAuth 2.1. Le serveur est un serveur de ressources et doit publier des métadonnées de ressources protégées (RFC 9728) nommant son serveur d'autorisation ; lorsqu'une demande arrive sans jeton, il répond 401 avec un en-tête WWW-Authenticate pointant vers ces métadonnées et, idéalement, le minimum de portée nécessaire. Le client découvre les points de terminaison du serveur d'autorisation, s'identifie (les documents de métadonnées d'identifiant client sont la voie recommandée ; l'enregistrement dynamique est conservé pour la compatibilité), exécute un flux de code d'autorisation avec PKCE, et doit inclure l'URI canonique du serveur comme paramètre de ressource afin que le jeton soit lié uniquement à ce serveur. Le serveur doit valider ce public, doit refuser les jetons émis pour autre chose, et ne doit jamais transmettre un jeton à un autre service.

La conséquence pour un ERP est la plus importante. Parce que le jeton identifie une personne, le serveur peut varier le résultat de tools/list par les identifiants de la demande, et la spécification le dit explicitement. C'est le mécanisme de filtrage basé sur les rôles : la liste d'un utilisateur financier et la liste d'un utilisateur d'entrepôt proviennent du même serveur et sont différentes. Une portée insuffisante à l'exécution est signalée par un 403 et un défi de portée dont le client peut s'élever, bien que pour la plupart des systèmes d'entreprise, la véritable frontière soit le rôle dans l'ERP plutôt que la portée OAuth grossière.

La partie difficile : autorisations et transactions

Tout ce qui précède peut être mis en œuvre en un après-midi avec un SDK. Ce qui sépare un serveur ERP MCP d'une démo est le traitement des deux choses que le protocole laisse au serveur : si un appel est autorisé et ce qu'un appel signifie.

La permission doit être vérifiée deux fois. Filtrer la liste des outils empêche le modèle de choisir quelque chose qu'il ne devrait pas, ce qui économise des jetons et évite la confusion. Vérifier à nouveau lorsque l'outil s'exécute est la véritable frontière, car un client peut envoyer n'importe quel appel qu'il souhaite. Un refus est mieux retourné comme une erreur d'exécution d'outil, afin que le modèle le lise et le rapporte, plutôt que comme un échec de transport qui met fin au tour. Voici à quoi ressemble un appel refusé depuis un espace de travail Sois : un résultat normal, signalé, avec une raison.

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Tool not permitted for this account: approveInvoice requires the finance approver role."
      }
    ],
    "isError": true
  }
}

Un refus de permission retourné comme une erreur d'exécution d'outil. Le modèle apprend pourquoi et peut demander à la personne d'approuver à la place ; rien n'a été écrit. Sois réserve également des codes d'erreur JSON-RPC pour les sessions non autorisées, les crédits insuffisants, les outils non autorisés et les plafonds budgétaires atteints.

Les transactions sont la seconde moitié. Un outil doit correspondre à une transaction commerciale avec un avant et un après clairs : Créer une facture produit un brouillon avec un identifiant, enregistrerPaiement applique un paiement à une facture, et aucun ne laisse un état à moitié écrit s'il échoue. Les modèles réessaient, donc les écritures doivent être sûres à répéter ou doivent refuser une répétition avec un message clair ; les annotations de la spécification permettent à un serveur de déclarer un outil comme en lecture seule, idempotent ou destructeur, et des clients comme ChatGPT utilisent ces indices pour décider s'ils doivent demander une confirmation. Lorsqu'une étape nécessite une décision qui dépasse l'autorité de l'agent, le serveur peut retourner un résultat nécessitant une entrée demandant à la personne une question via le client, plutôt que de deviner.

Comment Sois en implémente un

Un espace de travail Sois est un serveur MCP à une seule URL, l'adresse de l'espace de travail suivie de /api/mcpIl répond au défi 401 avec des métadonnées de ressources protégées, publie ses métadonnées de serveur d'autorisation, nécessite PKCE et émet des jetons limités à l'espace de travail ; un connecteur dans Claude ou ChatGPT complète la connexion sans rien coller. Un jeton d'accès avec une clé API est disponible pour les scripts qui ne font pas d'OAuth, avec l'identité et les dépenses conservées dans des identifiants séparés intentionnellement.

La liste des outils est générée à partir des définitions d'outils en direct et filtrée par rôle et applications installées, puis chaque appel est vérifié en termes de permissions à l'exécution et échoue en toute sécurité. Les appels sont limités en fréquence par connexion, mesurés lorsque l'agent propre de l'espace de travail effectue le raisonnement et exempts de frais d'IA lorsque l'agent du demandeur le fait, plafonnés par un budget défini par l'espace de travail, et enregistrés avec les entrées et les résultats contre la personne qui les a effectués. Les applications publiées sur le marché ajoutent leurs outils à la même liste selon les mêmes règles, de sorte qu'une application de développeur est opérationnelle par un agent dès son installation.

Questions que les gens posent

Cet article est révisé lorsque les produits qu'il décrit changent. Prochaine révision prévue : 4 décembre 2026.