Un serveur MCP sans serveur connecte les agents d'IA aux lacs de données sur AWS

Amazon Web Services a publié une architecture de référence pour la création de serveurs Model Context Protocol (MCP) sans serveur qui connectent les agents d'intelligence artificielle aux lacs de données d'entreprise. La conception, mise en œuvre pour le réseau des centres de tri nord-américains d'Amazon, utilise Amazon Elastic Container Service avec AWS Fargate pour fournir une passerelle centralisée permettant un accès conversationnel aux données. Cette approche vise à éliminer le besoin de code d'intégration personnalisé pour chaque nouveau jeu de données ou agent.

Ce qui s'est passé

Les organisations ont souvent du mal à donner aux agents des grands modèles de langage un accès sécurisé aux données internes sans dupliquer les efforts. Les équipes connectent généralement les agents directement aux bases de données, intégrant une logique unique de génération SQL et des contrôles d'accès dans chaque application. À mesure que le nombre de jeux de données augmente, cette approche fragmentée entraîne une dérive des permissions et rend l'intégration de nouvelles sources de données une tâche d'ingénierie de plusieurs jours. Pour remédier à cela, les ingénieurs d'AWS ont construit un serveur MCP partagé servant d'interface agnostique vis-à-vis des agents pour leur lac de données opérationnel.

La solution sépare les responsabilités en quatre couches distinctes : client, serveur MCP, outils et actualisation de la base de connaissances. Cette structure permet à chaque composant de monter en charge indépendamment tout en maintenant des limites de sécurité strictes. En centralisant la connexion au lac de données, l'équipe a garanti que n'importe quel client compatible MCP puisse interroger les métriques opérationnelles, les analyses commerciales et les données spécifiques au domaine sans réimplémenter la logique d'intégration principale. Le système prend en charge plusieurs locataires et applications, offrant une expérience cohérente à travers différentes interfaces utilisateur telles que les chats web ou les plugins IDE.

Une caractéristique clé de cette implémentation est sa conception pilotée par les métadonnées. Au lieu d'écrire du code pour définir comment un agent interagit avec une table spécifique, les ingénieurs ajoutent un fichier de métadonnées JSON. Le serveur découvre automatiquement ces fichiers lors des synchronisations de pipeline, rendant les nouveaux jeux de données immédiatement disponibles pour tous les agents connectés. Cette approche configuration-driven réduit le temps nécessaire pour intégrer une nouvelle source de données de plusieurs jours à quelques minutes, supprimant le goulot d'étranglement lié au développement d'outils personnalisés pour chaque changement de schéma.

Comment cela fonctionne

L'architecture repose sur un modèle d'exécution sans état alimenté par Amazon ECS Fargate. Lorsqu'un utilisateur soumet une requête, celle-ci passe par un Application Load Balancer et Amazon Cognito pour l'authentification. La demande est enrichie de configurations de mappage de contexte qui limitent la portée de la requête aux tables pertinentes, réduisant le bruit et améliorant la précision. Le serveur MCP, construit avec le framework Python FastMCP, orchestre l'interaction entre l'agent et les outils de données. Il récupère l'historique de session depuis Amazon DynamoDB et utilise Amazon Bedrock pour analyser l'intention et sélectionner les outils appropriés.

L'accès aux données est géré via un catalogue de métadonnées qui stocke les descriptions de schéma, la sémantique des colonnes et les relations entre les tables. Lorsqu'un agent doit interroger un jeu de données, il consulte d'abord ce catalogue pour comprendre la structure. L'agent génère ensuite une requête SQL, qui est validée pour la sécurité et la compatibilité avant son exécution sur Amazon Athena ou Amazon Redshift. Ce processus garantit que seules les opérations en lecture seule atteignent le lac de données, empêchant les écritures ou suppressions accidentelles. Les fichiers de métadonnées incluent des descriptions commerciales et des valeurs d'exemple, aidant l'agent à générer des clauses WHERE précises et à comprendre les exigences syntaxiques spécifiques au moteur.

Détails clés

• Le système utilise Amazon ECS Fargate pour les couches client et serveur MCP, assurant une mise à l'échelle élastique pour les charges de travail IA irrégulières.
• L'intégration d'un jeu de données ne nécessite qu'un fichier de métadonnées JSON, qui capture le schéma, le contexte commercial et la sémantique au niveau des colonnes.
• Amazon Bedrock Guardrails sont appliqués à toutes les interactions avec le modèle pour filtrer le contenu nuisible et bloquer les tentatives d'injection de prompt.
• Les configurations de mappage de contexte permettent aux ingénieurs de limiter les requêtes à des tables spécifiques, maintenant la latence de bout en bout entre 15 et 20 secondes.
• La couche d'outils comprend des outils de requête SQL pour Amazon Athena et Redshift, ainsi que la recherche sémantique via Amazon Bedrock Knowledge Bases.
• L'état de session est persisté dans Amazon DynamoDB, permettant aux tâches Fargate de rester sans état et facilement remplaçables.

Pourquoi c'est important

Pour les ingénieurs logiciels développant des applications IA, cette architecture offre un plan directeur pour gérer la complexité à grande échelle. En découplant la logique de l'agent de la couche d'accès aux données, les équipes peuvent éviter la charge de maintenance liée à la mise à jour de chaque agent lorsqu'un schéma de base de données change. L'application centralisée des contrôles d'accès répond également à une préoccupation de sécurité critique, garantissant que les politiques de permission sont appliquées de manière cohérente, quel que soit le client ou l'agent effectuant la demande. Cela réduit le risque d'exposition non autorisée des données dans les environnements multi-locataires.

L'approche pilotée par les métadonnées abaisse considérablement la barrière à l'entrée pour l'ajout de nouvelles sources de données. Au lieu d'exiger une connaissance approfondie de la génération SQL ou de l'intégration API, les ingénieurs peuvent se concentrer sur la définition de sémantiques commerciales claires dans des fichiers JSON. Ce changement permet une itération plus rapide et permet aux parties prenantes non techniques de contribuer à la base de connaissances de l'agent en fournissant des descriptions précises et des données d'exemple. À mesure que les agents IA deviennent plus présents dans les environnements d'entreprise, de telles passerelles standardisées seront essentielles pour maintenir la gouvernance et l'efficacité opérationnelle.

Ce que vous pouvez faire

• Évaluez vos intégrations d'agents actuelles pour identifier la logique d'accès aux données dupliquée qui pourrait être centralisée.
• Définissez un schéma JSON standard pour les fichiers de métadonnées incluant des descriptions commerciales et des valeurs d'exemple pour vos jeux de données.
• Implémentez des configurations de mappage de contexte pour limiter les requêtes des agents et réduire la latence dans les scénarios à haut volume.
• Utilisez des conteneurs sans serveur comme AWS Fargate pour gérer les motifs de charge variable typiques des interactions avec les agents IA.
• Appliquez des garde-fous au niveau du serveur pour assurer une sécurité du contenu cohérente et prévenir l'injection de prompts sur tous les clients.
• Stockez l'état de session dans une base de données durable et à faible latence comme DynamoDB pour prendre en charge les architectures de serveurs sans état.