Registre MCP et passerelle IA : architecture et cas d'utilisation en entreprise

Entre 2020 et 2023, des modèles de fondations tels que GPT-3 et GPT-4 a prouvé que les grands modèles de langage peuvent générer du texte semblable à un humain, écrire du code, résumer des documents et répondre à des questions complexes, mais ces modèles étaient apatride et en bac à sable, ils ne pouvaient pas accéder aux systèmes internes, aux bases de données ou aux applications, et n'avaient aucun moyen de prendre des mesures concrètes.

Vous pourriez demander à un mannequin :

»Écrivez une requête MongoDB pour répertorier toutes les collections de la base de données de conformité.»

Cela générerait une sortie qui regardait comme une requête MongoDB valide, mais :

• Il ne savait pas si la base de données existait
• Il ne savait pas quoi collections étaient présents dans la base de données
• Il n'a pas pu dire si la requête serait même exécutée
• Il n'y avait aucun moyen de inspecter les schémas, vérifier les résultats, ou déclencher des actions de suivi comme la synthèse ou la notification d'un autre système

C'était tout conjectures — avec pas de boucle de rétroaction.

Pour résoudre ce problème, les développeurs ont commencé à créer des couches autour des LLM :

• Enchaînement rapide
  
• Wrappers personnalisés en Python
  
• Injection d'appels d'API REST via des modèles de chaînes
  
• Remplissage manuel du contexte
  (« en utilisant le schéma suivant, écrivez la requête »)

C'étaient des solutions intelligentes, mais plus difficile à entretenir.

Des frameworks tels que Chaîne Lang, Indice de lama, et Noyau sémantique a vu le jour pour organiser ces flux de travail. Ces outils ont aidé à organiser les choses, mais les problèmes n'ont pas disparu. Les modèles étaient toujours des champs hallucinants, ne pouvaient pas être injectés rapidement, n'étaient pas validés et ne disposaient d'aucune méthode standard pour exécuter les fonctions réelles définies. Chaque nouveau cas d'utilisation ressemblait à une réinvention de la roue.

Le véritable tournant s'est produit lorsque les développeurs ont réalisé :

»Nous n'avons pas besoin de modèles pour deviner les commandes. Nous en avons besoin pour appeler de vraies fonctions, de la même manière que les applications frontales appellent les API backend.»

Vers la mi-2023, OpenAI a introduit appel de fonction, permettant aux modèles de revenir structurés JSON sortie directement mappée à de véritables appels de fonction.

Il a redéfini ce qui était possible grâce à l'intégration de modèles

• Les LLM pouvaient désormais s'interfacer avec des outils en utilisant des entrées et des sorties clairement définies
  
• Les modèles se sont comportés comme Clients d'API, plutôt que des générateurs basés sur des suppositions
  
• Les tâches pourraient désormais être automatisé avec de multiples étapes et interactions avec le système

Les appels de fonctions ont entraîné l'essor de outils et agents — des modèles capables d'enchaîner les actions, de suivre les flux de travail et d'interagir avec des systèmes réels

Mais...
1. Chaque mise en œuvre a été spécifique au fournisseur.
2. Il n'y a pas eu de partage format standard pour savoir comment les outils ont été décrits ou invoqués.

C'est ici MCP (Model Context Protocol) entre — proposé en tant que protocole ouvert général pour une communication structurée entre les modèles et les outils externes. Au lieu de coder en dur les API des outils dans chaque application LLM, MCP propose un chargeur universel pour connexions AI-Tool — comme API ouverte, Anthropique etc. mais pour les outils d'appel LLM. Il est basé sur JSON-RPC 2.0, une spécification largement utilisée qui prend en charge les appels de procédure à distance (RPC) à l'aide de JSON.

Ce que MCP définit

• Comment un modèle peut appeler une méthode d'outil (par exemple, RunAggregation)
  
• Comment transmettre des paramètres et obtenir des réponses structurées
  
• Comment les outils décrivent les méthodes disponibles (via des schémas ou des manifestes)
  
• Une norme légère pour l'intégration d'outils dans n'importe quel backend (base de données, CLI, API cloud)

Considérez le MCP comme le contrat d'API entre un modèle et un outil. Sans protocole standard, toutes les intégrations sont nécessaires ingénierie personnalisée — coûteux, sujet aux erreurs et répétitif. MCP a résolu ce problème en créant une langue universelle, simplifiant une fois pour toutes les intégrations d'outils. Mais qu'est-ce que le MCP exactement et comment fonctionne-t-il dans la pratique ? Allons plus loin.

Protocole de contexte du modèle

‍MCP (Model Context Protocol) est un protocole léger spécialement conçu pour une communication structurée entre Modèles d'IA et outils externes.

À la base, MCP utilise JSON-RPC 2.0, un protocole éprouvé pour appeler des procédures distantes avec des entrées et des sorties structurées, idéal pour transformer les sorties LLM en appels d'outils réels.

Donc pourquoi inventer un autre protocole ?

Les options existantes telles que REPOS ou GraphQL sont soit trop génériques, soit trop détaillés, soit tout simplement trop fragiles pour les flux de travail axés sur l'IA. MCP comble cette lacune en fournissant une structure claire, des frais généraux minimaux et en mettant explicitement l'accent sur les flux de travail centrés sur l'IA. Il n'est pas destiné à remplacer vos API, mais à permettre aux modèles de les utiliser de manière sûre, reproductible et prévisible.

• Application hôte: orchestre les appels d'outils, gère les sorties LLM, chaîne les réponses, par exemple, un agent GRC qui interroge Mongo, résume les résultats et envoie des alertes.
• Serveur MCP: implémente une logique spécifique au domaine, telle que ListCollections, RunAggregation ou SendMessageToSlack.
• Client MCP: bibliothèque minimale qui gère le formatage des demandes, l'authentification, les nouvelles tentatives et connecte l'hôte au serveur MCP approprié.

Les serveurs exposent généralement :

• Outils: commandes exécutables telles que ListCollections, RunAggregation ou SendSlackMessage.
• Ressources: données descriptives telles que les définitions de schéma, les métadonnées de collection ou la structure de la base de données.

En option, les serveurs peuvent également exposer :

• Promptes: invites/modèles standardisés pour les agents
• Primitives côté client: conseils de mise en cache ou de traitement par lots
• Notifications: flux d'événements en temps réel (via SSE)

Options de transport : STDIO contre HTTP/SSE

Le MCP est indépendant du transport et prend en charge deux modes :

Les deux transports suivent le même format JSON-RPC, ce qui vous permet de changer de transport sans réécrire la logique.

C'est donc l'idée maîtresse de MCP : un moyen minimal et propre pour les modèles d'appeler des outils sans colle fragile. Aucune commande hallucinée. Pas de remplissage de contexte manuel. Effacez simplement les entrées et les sorties. Mais comment cela fonctionne-t-il réellement dans une application réelle ? Voyons un exemple avec un assistant de conformité alimenté par MongoDB.

Automatiser un flux de travail GRC à l'aide de Mongo-MCP

Imaginez que vous êtes en train de créer un assistant GRC (Gouvernance, Risque et Conformité).

Cet assistant doit :

• Récupérez les collections et les journaux d'audit à partir d'une base de données MongoDB
• Résumer les résultats à l'intention d'un responsable de la conformité
• Avertissez les équipes concernées sur Slack
• Vous pouvez éventuellement déposer un problème de suivi sur GitHub

Dans une configuration traditionnelle, vous devez intégrer cette logique à l'aide d'appels REST ou de scripts Python, en insérant des schémas et des informations d'identification dans des modèles d'invite. Chaque intégration serait personnalisée et fragile.

Avec MCP, chacun de ces outils (MongoDB, Slack, GitHub) devient un fournisseur de fonctions de premier ordre, exposant des méthodes clairement définies telles que :

• Collections de listes
• Exécuter l'agrégation
• Envoyer un message
• Créer un problème

L'agent GRC (notre application hôte) appelle simplement ces outils à l'aide du schéma JSON-RPC de MCP

Scénario: Détecter et signaler les violations des règles Instructions destinées à l'utilisateur : »Consultez la base de données de conformité pour détecter toute violation des règles dès aujourd'hui et informez-en l'équipe sur Slack.»

1. Entrée utilisateur → Application hôte → LLM L'agent GRC (application hôte) envoie le message utilisateur au modèle. Le modèle est sensible aux outils et répond par les moyens suivants :

{
  "tool_calls": [
    {
      "name": "listCollections",
      "arguments": {
        "database": "compliance"
      }
    }
  ]
}

2. L'application hôte invoque Mongo-MCP via le client MCP Cet appel d'outil est converti en une requête JSON-RPC :

{
  "jsonrpc": "2.0",
  "method": "listCollections",
  "params": {
    "database": "compliance"
  },
  "id": "req-001"
}

3. Mongo-MCP Exécute la fonction Mongo-MCP mappe cet appel à :

def listCollections(database: str) -> List[str]:
    return mongo_client[database].list_collection_names()

Il exécute la fonction, obtient le résultat et répond :

{
  "jsonrpc": "2.0",
  "result": [
    "audit_logs",
    "policy_violations",
    "user_sessions"
  ],
  "id": "req-001"
}

4. L'agent enchaîne l'appel suivant : RunAggregation Le modèle génère désormais un appel de suivi en fonction des collections disponibles :

{
  "tool_calls": [
    {
      "name": "runAggregation",
      "arguments": {
        "database": "compliance",
        "collection": "policy_violations",
        "pipeline": [
          { "$match": { "timestamp": { "$gte": "2025-08-05" } } },
          { "$group": { "_id": "$severity", "count": { "$sum": 1 } } }
        ]
      }
    }
  ]
}

Cela entraîne un autre appel JSON-RPC à Mongo-MCP, et le serveur renvoie :

{
  "jsonrpc": "2.0",
  "result": [
    { "_id": "high", "count": 5 },
    { "_id": "medium", "count": 12 }
  ],
  "id": "req-002"
}

L'agent renvoie ce résultat au modèle avec une invite telle que :

»Résumez ces données de violation de politique en anglais clair. »

Le modèle répond :

« TAujourd'hui, la base de données de conformité a enregistré 5 violations de politique de gravité élevée et 12 de gravité moyenne.»

5. Model appelle Slack-MCP pour avertir l'équipe À présent, l'agent lance un dernier appel d'outil structuré :

{
  "tool_calls": [
    {
      "name": "sendMessage",
      "arguments": {
        "channel": "#compliance-alerts",
        "message": "5 high and 12 medium policy violations detected today. Please review."
      }
    }
  ]
}

Le serveur Slack-MCP envoie le message et le flux de travail est terminé. Tout cela s'est produit grâce à des appels JSON structurés, et non à la manipulation de chaînes ou à une ingénierie rapide.

Governing Enterprise AI at Scale: The MCP Gateway Blueprint

$2 Million

The

Wake-Up Call

Your integration architecture determines whether AI becomes a competitive advantage or unmanageable risk.

A Fortune 500 Spent $2M Fixing Ungoverned AI

Don't let this be you, get the complete Al governance blueprint.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Pourquoi avez-vous besoin d'un registre de serveurs MCP dans MCP Gateway ?

La démo de Mongo-MCP semble propre. Le modèle a effectué des appels d'outils structurés. Chaque fonction a fonctionné comme prévu. Pas d'hallucinations. Pas de modèles de chaînes fragiles. Mais c'est une voie heureuse, et les vrais systèmes ne se contentent pas de fonctionner... ils doivent fonctionner de manière sûre, fiable et observable à grande échelle.

En production, le MCP brut est insuffisant dans quelques domaines clés :

1. Aucun contrôle d'accès (RBAC) Raw MCP n'a aucun moyen intégré de restreindre qui peut appeler quoi.

• Et si vous souhaitez autoriser l'exécution de l'agrégation mais bloquer DeleteCollection ?
• Et si un modèle devait uniquement interroger certains ensembles de données (par exemple, les finances ne peuvent pas accéder aux ressources humaines) ?

Dans les organisations réelles, le RBAC (contrôle d'accès basé sur les rôles) n'est pas négociable, en particulier lorsque les modèles sont connectés à des outils sensibles.

2. Aucune clé d'authentification ou d'API que Raw MCP ne gère pas

• Validation de l'agent ou du modèle qui effectue l'appel
• Identification des compétences par équipe, environnement ou projet
• Expiration ou révocation du jeton

Cela signifie que toute personne ayant accès au serveur mcp peut appeler n'importe quel outil, et il n'y a aucune piste d'audit.

3. Aucune observabilité Vous ne pouvez pas corriger ce que vous ne pouvez pas voir.

• Quelle est la latence de chaque appel d'outil ?
• Quel est le taux d'échec ou le nombre de tentatives ?
• Quels outils sont surutilisés ou arrivent à expiration ?

Avec le MCP brut, vous n'avez pas de tableaux de bord, de journaux ou de traces. Tu voles à l'aveugle.

4. Les LLM de No Guardrails sont créatifs, parfois trop créatifs.

Raw MCP possède :

• Aucune limite de jetons (par exemple, empêchez les agrégations massives)
• Aucune limite de taille de résultat (par exemple, renvoyer 5 Mo depuis Mongo)
• Pas de disjoncteur ni d'invite de pause (par exemple, « Êtes-vous sûr de vouloir envoyer cette alerte Slack ? »)

En l'absence de barrières, un bogue rapide peut entraîner l'envoi de milliers de messages Slack ou l'effacement accidentel de données.

5. Pas de nouvelle tentative, de limitation ou de quota en production

En production, les outils ne se comportent pas toujours parfaitement : ils peuvent tomber en panne, s'arrêter ou réagir lentement. Sans mesures de protection, même les modèles qui se comportent bien peuvent :

• Limites de taux de réussite
  
• Hammer Services avec nouvelles tentatives
  
• Exposez les outils sensibles à une mauvaise utilisation
  

Le protocole MCP brut part du principe que tout fonctionne parfaitement : un monde « sur la bonne voie ». Mais l'infrastructure du monde réel est compliquée. Vous avez besoin d'une logique de nouvelle tentative intelligente, d'une mise en cache, d'une limitation de débit et d'un contrôle d'accès pour rester en bonne santé à grande échelle.

• Authentification + accès basé sur des jetons
• RBAC par modèle, utilisateur, organisation et outil
• Observabilité et traçage
• Quotas, limites et stratégies de nouvelle tentative
• Flux de travail d'approbation pour les actions sensibles

C'est exactement ce que propose la passerelle TrueFoundry.

Des démonstrations sur un seul serveur aux flux de travail d'agents destinés aux entreprises

Dans le première moitié de cet article, nous avons appris ce qu'est le Model-Context-Protocol et avons utilisé un Serveur Mongo MCP pour automatiser une ancienne plateforme GRC. Cet exemple de jouet est idéal pour une journée de piratage, mais il se heurte rapidement à des difficultés dans le monde réel :

TrueFoundry Passerelle IA regroupe la plomberie manquante (un registre MCP, une authentification centrale, un RBAC, des garde-corps et une observabilité complète) afin que les équipes puissent passer de « agent du monde entier » pour production en toute sécurité et de manière répétée.

Ce que la passerelle ajoute au MCP brut

TrueFoundry positionne la passerelle comme plan de contrôle qui se trouve entre vos agents (ou l'interface utilisateur de chat) et tous les serveurs MCP et fournisseurs LLM enregistrés.

Les fonctionnalités clés incluent :

1. Registre MCP central — ajoutez une fois des serveurs publics ou auto-hébergés ; découvrez-les partout
2. Informations d'identification unifiées — générer un seul Token d'accès personnel (PAT) ou jeton de compte virtuel (VAT) à portée de machine qui est automatiquement échangé contre des jetons OAuth/d'en-tête par serveur en arrière-plan
3. RBAC à grain fin — restreindre lequel les utilisateurs, les applications ou les environnements peuvent voir ou exécuter lequel outils
4. Agent Playground et client MCP intégré — prototypage rapide sans écrire de ligne de code
5. Observabilité et garde-corps — latence, coût, traces, flux d'approbation, limites de débit et mise en cache intégrés

Considérez-le comme le Passerelle API + maillage de service + boutique secrète pour l'environnement émergent du MCP. « Comme indiqué dans Guide d'authentification du serveur MCP, la passerelle gère automatiquement le stockage des informations d'identification et le cycle de vie des jetons. »

Pratique : enregistrement de votre premier serveur MCP

La toute première étape de l'interface utilisateur consiste à créer un groupe—par exemple dev-mcps ou prod-mcps. Les groupes vous permettent d'associer différentes règles RBAC et différents flux d'approbation à différents environnements.

« Vous pouvez suivre le Guide de démarrage du serveur TrueFoundry MCP pour des étapes détaillées. »

Serveurs MCP AI Gateway ➜ ➜ « Ajouter un nouveau groupe de serveurs MCP »

name: prod-mcps
   access control:
       - Manage: SRE-Admins
       - User  : Prod-Runtime-Service-Accounts

Au sein du groupe, choisissez Ajouter/modifier un serveur MCP et remplissez trois champs :

Vous pouvez tout aussi facilement ajouter :

• Pas d'authentification serveurs de démonstration (par exemple, Calculator)
• Authentification de l'en-tête serveurs qui acceptent une clé API statique (par exemple, Hugging Face)
• Nombre illimité de futurs serveurs (Atlassian, Datadog, micro-services internes)

Dans les coulisses, la passerelle stocke les informations d'identification dans sa boutique secrète et gère l'actualisation des jetons.

Authentification et RBAC

TrueFoundry prend en charge trois schémas d'authentification par serveur MCP :

« Ces modes sont décrits plus en détail dans Documentation sur l'authentification des serveurs MCP. »

Une fois qu'un serveur est enregistré, ne remettez des jetons bruts à chaque développeur. Au lieu de cela, ils s'authentifient une fois que à la passerelle et recevez :

• PAT — adapté à l'utilisateur, convivial, idéal pour la CLI et les expériences
• TVA — compte de service limité, verrouillé sur certains serveurs, idéal pour les applications de production

La passerelle compare le jeton d'appel à :

1. Au niveau du groupe autorisations (cet utilisateur peut-il accéder à n'importe quel serveur dans prod-mcps ?)
2. Au niveau du serveur autorisations (est-ce que Slack-mcp est sur la liste blanche ?)
3. Au niveau de l'outil autorisations (peuvent-ils appeler SendMessageToChannel ?)

Si une vérification échoue, la demande est rejetée avant il accède à votre espace de travail Slack.

De Playground à Code : l'API des agents

Après avoir expérimenté dans l'interface utilisateur, vous pouvez cliquer sur « Extrait de code d'API » pour générer des exemples fonctionnels en Python, JS ou cURL. Vous trouverez ci-dessous un taillé Corps JSON qui connecte trois serveurs ensemble (GitHub, Slack, Calculator) :

Post/API/LLM/Agent/Réponses

{
  "model": "gpt-4o",
  "stream": true,
  "iteration_limit": 5,
  "messages": [
    {
      "role": "user",
      "content": "Summarize open PRs on repo X and DM me the top blockers."
    }
  ],
  "mcp_servers": [
    {
      "integration_fqn": "truefoundry:prod-mcps:github-mcp",
      "tools": [ {"name": "listPullRequests"}, {"name": "createComment"} ]
    },
    {
      "integration_fqn": "truefoundry:prod-mcps:slack-mcp",
      "tools": [ {"name": "sendMessageToUser"} ]
    },
    {
      "integration_fqn": "truefoundry:common:calculator-mcp",
      "tools": [ {"name": "add"} ]
    }
  ]
}

« Vous pouvez trouver un exemple similaire dans Utiliser le serveur MCP dans le guide Code Agent, qui inclut également des extraits complets de code Python et JS. »

Le diffusion en continu la réponse s'entrelace :

1. assistant jetons (raisonnement LLM)
2. tool-call chunks (nom de la fonction + arguments incrémentiels)
3. résultat de l'outil événements (sortie JSON)

Cela vous permet de créer réactif Des interfaces utilisateur qui montrent chaque étape de la boucle agentique en temps réel.

Observabilité, garde-fous et politiques

Même un agent « Hello World » peut coûter de l'argent réel et faire de réels dégâts. TrueFoundry offre une observabilité de premier ordre :

• Tableaux de bord de latence et d'erreurs — TTFT, latence des tâches, erreurs HTTP, nouvelles tentatives d'outils
• Suivi des jetons et des coûts — dépenses attributaires par modèle, par équipe, par indicateur de fonctionnalité
• Ouvrir les traces de télémétrie — des étapes étape par étape entre les agents, Proxy MCP, et LLM
• Limites de débit et mise en cache — évitez les boucles incontrôlables et réutilisez des résultats de recherche identiques sur le Web
• Crochets pour garde-corps — appliquez le nettoyage des informations personnelles, les filtres NSFW ou l' « approbation humaine » sur tout outil destructeur

Tous les indicateurs sont prêts à l'emploi ; aucun agent de side-car ou exportateur personnalisé n'est requis.

Soutenant Tous MCP Transports (HTTP et STDIO)

De nombreux serveurs open source parlent encore studio (stdin/stdout) au lieu de HTTP. TrueFoundry recommande de les emballer avec proxy mcp et déploiement en tant que service régulier

# wrap a Python stdio server
mcp-proxy --port 8000 --host 0.0.0.0 --server stream python my_server.py

Des modèles prêts à l'emploi existent pour les serveurs Notion et Perplexity, ainsi que des manifestes K8s pour les images Node ou Python. Une fois le proxy activé, l'enregistrement est identique à tout autre point de terminaison HTTP MCP.

« TrueFoundry » Guide du serveur MCP STDIO couvre cette approche de proxy et fournit des modèles de déploiement. »

Exemple de procédure pas à pas : Enterprise Compliance Bot

Revenons à notre héritage GRC scénario mais augmentez l'ambition :

« Tenez à jour nos preuves de conformité. Si un fichier de règles change dans GitHub, stockez la différence dans MongoDB, créez un ticket Jira et publiez un résumé dans Slack. »

Serveurs concernés

Flux

1. Webhook GitHub accède à une fonction cloud.
2. La fonction appelle le API d'agent (jeton de TVA) avec les quatre serveurs activés.
3. Raisons LLM → appels GitHub.GetFileDiff → Mongo.InsertDocument → Jira.CreateIssue → Slack.SendMessage.
4. Chaque appel d'outil et chaque résultat sont renvoyés ; l'observabilité capture la latence de chaque saut.
5. Si la différence est > x (un certain nombre de lignes de code, comme seuil), un garde-corps inserts « nécessite une approbation manuelle » et interrompt l'exécution ; un responsable de sécurité peut approuver via l'interface utilisateur de Gateway.

Gouvernance

• La TVA attachée à la fonction ne voit que les quatre serveurs répertoriés :moindre privilège.
• Séparer dev et prod les groupes vous permettent de tester Jira dans un sandbox et de tester Slack.
• Les auditeurs peuvent rejouer n'importe quel incident : les traces et les charges utiles JSON complètes sont conservées 30 jours par défaut.

Extension de l'écosystème : création de votre propre serveur MCP

Parce que MCP est juste JSON-RPC sur HTTP ou stdio, n'importe quel Un service interne peut exposer des outils, en voici un petit exemple :

• Déposez ce conteneur dans votre cluster Kubernetes.
• Enregistrez-le dans dev groupe avec Pas d'authentification pendant le développement.
• Passez à Authentification de l'en-tête ou OAuth2 avant de le déplacer vers prod-mcps.

À partir de ce moment, chaque Un agent de votre entreprise peut raisonner sur les contrôles de conformité avec exactement la même ergonomie que Slack ou GitHub.

Aide-mémoire sur les meilleures pratiques

« Cette fiche a été adaptée du Présentation de TrueFoundry MCP, ces directives contribuent à garantir des déploiements sûrs et fiables. »

Conclusion

MCP permet aux grands modèles linguistiques (LLM) de parler le même langage que les outils, mais il ne gère pas des aspects tels que la sécurité, la découverte ou la gouvernance au niveau de l'entreprise. C'est là qu'intervient la passerelle IA de TrueFoundry : elle ajoute tout ce dont les équipes ont besoin dès le départ, comme un Registre MCP, une authentification intégrée, un contrôle d'accès basé sur les rôles (RBAC), une observabilité approfondie et une puissante API d'agent pour relier le tout.

Questions fréquemment posées

Qu'est-ce qu'un registre MCP dans les systèmes d'IA ?

Un registre MCP est un catalogue centralisé qui stocke et gère les serveurs MCP (Model Context Protocol) disponibles et leurs fonctionnalités spécifiques. Il agit comme un répertoire consultable pour les agents d'IA, leur permettant de découvrir de manière dynamique des outils et des ressources. Ce registre garantit que les modèles peuvent identifier les services appropriés nécessaires à l'exécution de tâches complexes en plusieurs étapes.

Quelle est la différence entre un registre MCP et une passerelle AI ?

Un registre MCP est un répertoire passif d'outils, tandis qu'une passerelle IA est la couche d'application active qui gère le trafic. Le registre indique au système quelles ressources existent, tandis que la passerelle contrôle l'accès, gère l'authentification et applique des politiques de sécurité telles que le masquage des informations personnelles ou la limitation du débit lors de l'exécution effective des demandes de modèle.

Une passerelle IA peut-elle fonctionner sans registre MCP ?

Oui, une passerelle IA peut fonctionner sans registre MCP à l'aide de configurations statiques, mais elle perd la flexibilité de la découverte dynamique d'outils. Sans registre, les développeurs doivent coder manuellement chaque connexion au serveur, ce qui complique la mise à l'échelle et la maintenance du système. L'intégration d'un registre permet à la passerelle de s'adapter automatiquement à mesure que de nouveaux outils sont ajoutés à l'écosystème.

Comment une passerelle IA applique-t-elle les politiques d'un registre MCP ?

La passerelle AI récupère les métadonnées et les règles de gouvernance du registre MCP pour valider les demandes entrantes en temps réel. Il recoupe les autorisations des utilisateurs et les exigences de sécurité définies dans le registre avant d'acheminer le trafic vers le serveur approprié. Cela garantit que chaque interaction reste conforme aux normes organisationnelles et aux protocoles de résidence des données.