Serveur MCP TypeScript

Générez un serveur Model Context Protocol (MCP) en TypeScript pour fournir du contexte aux Grands Modèles de Langage (LLM), avec option de déploiement sur Amazon Bedrock AgentCore.

Qu’est-ce que le MCP ?

Le Model Context Protocol (MCP) est un standard ouvert permettant aux assistants IA d’interagir avec des outils et ressources externes. Il fournit une méthode cohérente pour que les LLM puissent :

• Exécuter des outils (fonctions) réalisant des actions ou récupérant des informations
• Accéder à des ressources fournissant du contexte ou des données

Utilisation

Générer un serveur MCP

Vous pouvez générer un serveur MCP en TypeScript de deux manières :

VSCode

1. Installez le Nx Console VSCode Plugin si ce n'est pas déjà fait
2. Ouvrez la console Nx dans VSCode
3. Cliquez sur Generate (UI) dans la section "Common Nx Commands"
4. Recherchez @aws/nx-plugin - ts#mcp-server
5. Remplissez les paramètres requis
6. Cliquez sur Generate

CLI

pnpm

pnpm nx g @aws/nx-plugin:ts#mcp-server

yarn

yarn nx g @aws/nx-plugin:ts#mcp-server

npm

npx nx g @aws/nx-plugin:ts#mcp-server

bun

bunx nx g @aws/nx-plugin:ts#mcp-server

Vous pouvez également effectuer une simulation pour voir quels fichiers seraient modifiés

pnpm

pnpm nx g @aws/nx-plugin:ts#mcp-server --dry-run

yarn

yarn nx g @aws/nx-plugin:ts#mcp-server --dry-run

npm

npx nx g @aws/nx-plugin:ts#mcp-server --dry-run

bun

bunx nx g @aws/nx-plugin:ts#mcp-server --dry-run

Prérequis du projet

Utilisez d’abord le générateur ts#project pour créer un projet auquel ajouter votre serveur MCP.

Options

Paramètre	Type	Par défaut	Description
project Requis	string	-	Le projet auquel ajouter un serveur MCP
name	string	-	Le nom de votre serveur MCP (par défaut : mcp-server)
auth	iam | cognito	iam	La méthode utilisée pour s'authentifier auprès de votre serveur MCP. Applicable uniquement lorsque infra est défini (ignoré lorsque infra est none).
iac	inherit | cdk | terraform	inherit	Le fournisseur IaC préféré. Par défaut, cette valeur est héritée de votre sélection initiale.
infra	agentcore | none	agentcore	Le type d'infrastructure pour héberger votre serveur MCP. Sélectionnez none pour aucun hébergement.
preferInstallDependencies	boolean	true	Indique s'il faut privilégier l'installation des dépendances après l'exécution du générateur. Définir sur false pour différer l'installation lors de l'exécution de plusieurs générateurs en lot (une installation s'exécute quand même si nécessaire pour que les générateurs suivants puissent calculer le graphe de projet Nx) ; installer une seule fois à la fin.

Résultat du générateur

Le générateur ajoutera les fichiers suivants à votre projet TypeScript existant :

• Répertoireyour-project/

  • Répertoiresrc/

    • Répertoiremcp-server/ (ou nom personnalisé si spécifié)

      • index.ts Exporte votre serveur
      • server.ts Définition principale du serveur
      • stdio.ts Point d’entrée pour le transport STDIO, utile pour des serveurs MCP locaux simples
      • http.ts Point d’entrée pour le transport HTTP streamable, utile pour héberger votre serveur MCP
      • Répertoiretools/

        • divide.ts Exemple d’outil
      • Répertoireresources/

        • sample-guidance.ts Exemple de ressource
      • Dockerfile Point d’entrée pour héberger votre serveur MCP (exclu si infra est défini sur None)
  • project.json Mis à jour avec la cible de service du serveur MCP

Infrastructure

infra = agentcore

Ce générateur fournit de l’infrastructure as code basée sur votre iacProvider choisi. Il créera un projet dans packages/common qui inclut les constructions CDK ou modules Terraform pertinents.

Le projet commun d’infrastructure as code est structuré comme suit :

CDK

• Répertoirepackages/common/constructs

  • Répertoiresrc

    • Répertoireapp/ Constructions pour l’infrastructure spécifique à un projet/générateur

      • …
    • Répertoirecore/ Constructions génériques réutilisées par celles dans app

      • …
    • index.ts Point d’entrée exportant les constructions depuis app
  • project.json Cibles de build et configuration du projet

Projet généré

Ce projet est généré avec le générateur ts#project et configure donc les mêmes cibles de build.

Terraform

• Répertoirepackages/common/terraform

  • Répertoiresrc

    • Répertoireapp/ Modules Terraform pour l’infrastructure spécifique à un projet/générateur

      • …
    • Répertoirecore/ Modules génériques réutilisés par ceux dans app

      • …
  • project.json Cibles de build et configuration du projet

Projet généré

Ce projet est généré avec le générateur terraform#project et configure donc les mêmes cibles de build.

Pour le déploiement de votre serveur MCP, les fichiers suivants sont générés :

CDK

• Répertoirepackages/common/constructs/src

  • Répertoireapp

    • Répertoiremcp-servers

      • Répertoire<project-name>

        • <project-name>.ts Construct CDK pour déployer votre serveur MCP
        • Dockerfile Fichier Docker transmis directement utilisé par le construct CDK

Terraform

• Répertoirepackages/common/terraform/src

  • Répertoireapp

    • Répertoiremcp-servers

      • Répertoire<project-name>

        • <project-name>.tf Module pour déployer votre serveur MCP
  • Répertoirecore

    • Répertoireagent-core

      • runtime.tf Module générique pour le déploiement sur Bedrock AgentCore Runtime

infra = none

Si vous avez sélectionné None pour infra, aucun construct CDK ni module Terraform n’est généré — le serveur MCP est configuré uniquement pour une utilisation locale STDIO / HTTP. L’option auth est ignorée dans ce mode car il n’y a pas de point de terminaison hébergé à authentifier.

Architecture

Bedrock AgentCore Runtime

Lorsqu’il est déployé sur Bedrock AgentCore Runtime, le serveur MCP est construit dans une image de conteneur, poussé vers Amazon ECR et exécuté dans AgentCore Runtime. Les assistants IA invoquent le point de terminaison du plan de données AgentCore Runtime, qui transmet les appels tools/* et resources/* à votre serveur via le transport HTTP streamable.

None (local only)

Avec infra: None, aucune infrastructure AWS n’est générée. Le serveur MCP est configuré uniquement pour les transports STDIO et HTTP locaux, et est consommé par des assistants IA s’exécutant sur la même machine.

Utilisation de votre serveur MCP

Ajout d’outils

Les outils sont des fonctions que l’assistant IA peut appeler pour effectuer des actions. Vous pouvez ajouter de nouveaux outils dans le fichier server.ts :

server.registerTool("toolName", {
  description: "description de l'outil",
  inputSchema: { param1: z.string(), param2: z.number() } // Schéma d'entrée utilisant Zod
},
  async ({ param1, param2 }) => {
    // Implémentation de l'outil
    return {
      content: [{ type: "text", text: "Résultat" }]
    };
  }
);

Ajout de ressources

Les ressources fournissent du contexte à l’assistant IA. Vous pouvez ajouter des ressources statiques depuis des fichiers ou des ressources dynamiques :

const exampleContext = 'contexte exemple à retourner';

server.registerResource('resource-name', 'example://resource', {}, async (uri) => ({
  contents: [{ uri: uri.href, text: exampleContext }],
}));

// Ressource dynamique
server.registerResource('dynamic-resource', 'dynamic://resource', {}, async (uri) => {
  const data = await fetchSomeData();
  return {
    contents: [{ uri: uri.href, text: data }],
  };
});

Configuration avec des assistants IA

Fichiers de configuration

La plupart des assistants IA compatibles avec MCP utilisent une approche de configuration similaire. Vous devrez créer ou mettre à jour un fichier de configuration avec les détails de votre serveur MCP :

{
  "mcpServers": {
    "your-mcp-server": {
      "command": "npx",
      "args": ["tsx", "/path/to/your-mcp-server/stdio.ts"]
    }
  }
}

Résolution de chemin

Si vous recevez une erreur comme ENOENT npx lors de la connexion à votre serveur, vous devrez peut-être spécifier le chemin complet vers npx, que vous pouvez obtenir en exécutant which npx dans votre terminal.

Rechargement à chaud

Pendant le développement de votre serveur MCP, vous pouvez activer le flag --watch pour que l’assistant IA détecte toujours les dernières versions des outils/ressources :

{
  "mcpServers": {
    "your-mcp-server": {
      "command": "npx",
      "args": ["tsx", "--watch", "/path/to/your-mcp-server/stdio.ts"]
    }
  }
}

Actualiser les outils

Si vous ajoutez de nouveaux outils ou ressources, vous devrez peut-être rafraîchir votre serveur MCP dans l’assistant IA.

Configuration spécifique à l’assistant

Consultez la documentation suivante pour configurer MCP avec des assistants IA spécifiques :

• Kiro
• Kiro CLI
• Claude Code
• Cursor
• Codex
• Cline
• Roo Code

Configuration du workspace

Certains assistants IA comme Amazon Q Developer permettent de spécifier une configuration MCP au niveau de l’espace de travail, ce qui est particulièrement utile pour définir les serveurs MCP pertinents pour un projet donné.

Exécution de votre serveur MCP

Développement local

Pour exécuter votre serveur MCP (et tout ce qui y est connecté, comme une base de données locale) localement, utilisez la cible dev du projet :

pnpm

pnpm nx dev your-project

yarn

yarn nx dev your-project

npm

npx nx dev your-project

bun

bunx nx dev your-project

Si vous avez ajouté plusieurs composants à votre projet (serveurs MCP, agents, etc.), cela les démarre tous. Pour exécuter uniquement ce serveur MCP, ciblez sa cible <your-server-name>-dev :

pnpm

pnpm nx your-server-name-dev your-project

yarn

yarn nx your-server-name-dev your-project

npm

npx nx your-server-name-dev your-project

bun

bunx nx your-server-name-dev your-project

Inspecteur

Le générateur configure une cible nommée <your-server-name>-inspect, qui démarre votre serveur MCP localement (via la cible <your-server-name>-dev, incluant toutes les dépendances connectées telles qu’une base de données locale) et lance l’MCP Inspector préconfiguré pour s’y connecter via le transport HTTP Streamable.

pnpm

pnpm nx your-server-name-inspect your-project

yarn

yarn nx your-server-name-inspect your-project

npm

npx nx your-server-name-inspect your-project

bun

bunx nx your-server-name-inspect your-project

Ceci démarrera l’inspecteur sur http://localhost:6274. Commencez en cliquant sur le bouton “Connect”.

Astuce

Pour inspecter le serveur en utilisant le transport STDIO à la place, utilisez la cible <your-server-name>-inspect-stdio, qui lance l’inspecteur contre une instance STDIO de votre serveur.

STDIO

La méthode la plus simple pour tester et utiliser un serveur MCP est d’utiliser l’inspecteur ou de le configurer avec un assistant IA (comme ci-dessus).

Vous pouvez cependant exécuter votre serveur avec le transport STDIO directement en utilisant la cible <your-server-name>-serve-stdio.

pnpm

pnpm nx your-server-name-serve-stdio your-project

yarn

yarn nx your-server-name-serve-stdio your-project

npm

npx nx your-server-name-serve-stdio your-project

bun

bunx nx your-server-name-serve-stdio your-project

Cette commande utilise tsx --watch pour redémarrer automatiquement le serveur lors des modifications de fichiers.

HTTP Streamable

Si vous souhaitez exécuter votre serveur MCP localement avec le transport HTTP Streamable, utilisez la cible <your-server-name>-serve.

pnpm

pnpm nx your-server-name-serve your-project

yarn

yarn nx your-server-name-serve your-project

npm

npx nx your-server-name-serve your-project

bun

bunx nx your-server-name-serve your-project

Cette commande utilise tsx --watch pour redémarrer automatiquement le serveur lors des modifications de fichiers.

infra = agentcore

Déploiement sur Bedrock AgentCore Runtime

Infrastructure en tant que code

Si vous avez sélectionné agentcore pour infra, l’infrastructure CDK ou Terraform correspondante est générée. Vous pouvez l’utiliser pour déployer votre serveur MCP sur Amazon Bedrock AgentCore Runtime.

CDK

Un construct CDK est généré pour votre serveur MCP, nommé d’après le name choisi lors de l’exécution du générateur, ou <ProjectName>McpServer par défaut.

Vous pouvez utiliser ce construct CDK dans une application CDK :

import { MyProjectMcpServer } from ':my-scope/common-constructs';

export class ExampleStack extends Stack {
  constructor(scope: Construct, id: string) {
    // Ajoutez le serveur MCP à votre stack
    new MyProjectMcpServer(this, 'MyProjectMcpServer');
  }
}

Construct CDK

Ce construct utilise le module aws-cdk-lib/aws-bedrockagentcore.

Terraform

Un module Terraform est généré pour vous, nommé d’après le name choisi lors de l’exécution du générateur, ou <ProjectName>-mcp-server par défaut.

Transmettez les sorties du module partagé runtime_config_appconfig au module du serveur MCP :

module "my_project_mcp_server" {
  source = "../../common/terraform/src/app/mcp-servers/my-project-mcp-server"

  appconfig_application_id  = module.runtime_config_appconfig.application_id
  appconfig_application_arn = module.runtime_config_appconfig.application_arn
}

Docker requis

Docker est requis pour construire et déployer votre serveur MCP. Assurez-vous qu’il est installé et lancé pour éviter des erreurs comme :

ERROR: Cannot connect to the Docker daemon at unix://path/to/docker.sock.

Authentification

Le générateur fournit une option auth pour configurer l’authentification de votre serveur MCP. Vous pouvez choisir entre l’authentification IAM (par défaut) ou Cognito lors de la génération de votre serveur MCP.

IAM

Par défaut, votre serveur MCP sera sécurisé via l’authentification IAM. Déployez-le simplement sans arguments :

CDK

import { MyProjectMcpServer } from ':my-scope/common-constructs';

export class ExampleStack extends Stack {
  constructor(scope: Construct, id: string) {
    new MyProjectMcpServer(this, 'MyProjectMcpServer');
  }
}

Vous pouvez autoriser l’invocation de votre serveur MCP sur Bedrock AgentCore Runtime avec la méthode grantInvokeAccess. Par exemple, pour permettre à un agent généré avec le générateur py#agent d’appeler votre serveur MCP :

import { MyProjectAgent, MyProjectMcpServer } from ':my-scope/common-constructs';

export class ExampleStack extends Stack {
  constructor(scope: Construct, id: string) {
    const agent = new MyProjectAgent(this, 'MyProjectAgent');
    const mcpServer = new MyProjectMcpServer(this, 'MyProjectMcpServer');

    mcpServer.grantInvokeAccess(agent);
  }
}

Terraform

# Serveur MCP
module "my_project_mcp_server" {
  # Chemin relatif vers le module généré dans le projet common/terraform
  source = "../../common/terraform/src/app/mcp-servers/my-project-mcp-server"

  appconfig_application_id  = module.runtime_config_appconfig.application_id
  appconfig_application_arn = module.runtime_config_appconfig.application_arn
}

Pour autoriser l’invocation de votre serveur MCP, ajoutez une politique IAM faisant référence à la sortie module.my_project_mcp_server.agent_core_runtime_arn :

{
  Effect = "Allow"
  Action = [
    "bedrock-agentcore:InvokeAgentRuntime"
  ]
  Resource = [
    module.my_project_mcp_server.agent_core_runtime_arn,
    "${module.my_project_mcp_server.agent_core_runtime_arn}/*"
  ]
}

Authentification Cognito

Lorsque vous sélectionnez l’authentification Cognito, le générateur configure le serveur MCP pour utiliser Cognito pour l’authentification.

CDK

Le construct généré accepte une prop identity qui configure l’authentification Cognito :

import { MyProjectMcpServer, UserIdentity } from ':my-scope/common-constructs';

export class ExampleStack extends Stack {
  constructor(scope: Construct, id: string) {
    const identity = new UserIdentity(this, 'Identity');

    new MyProjectMcpServer(this, 'MyProjectMcpServer', {
      identity,
    });
  }
}

Le construct UserIdentity peut être généré en utilisant le générateur ts#website#auth, ou vous pouvez créer votre propre UserPool et UserPoolClient CDK.

Terraform

Le module généré accepte les variables user_pool_id et user_pool_client_ids pour l’authentification Cognito :

module "user_identity" {
  source = "../../common/terraform/src/core/user-identity"
}

module "my_project_mcp_server" {
  source = "../../common/terraform/src/app/mcp-servers/my-project-mcp-server"

  appconfig_application_id  = module.runtime_config_appconfig.application_id
  appconfig_application_arn = module.runtime_config_appconfig.application_arn

  user_pool_id         = module.user_identity.user_pool_id
  user_pool_client_ids = [module.user_identity.user_pool_client_id]
}

Fournisseurs OIDC personnalisés

Si vous avez besoin d’une authentification JWT personnalisée avec un fournisseur OIDC non-Cognito, vous pouvez modifier directement le construct CDK ou le module Terraform généré pour votre serveur MCP. Notez que le générateur de connexion ne prendra en charge que l’authentification IAM ou Cognito.

Bonnes pratiques de sécurité

Lors de l’implémentation de la logique métier de votre serveur MCP, consultez les bonnes pratiques de sécurité Bedrock AgentCore Runtime.

Cible de bundle

Le générateur configure automatiquement une cible bundle qui utilise Rolldown pour créer un package de déploiement :

pnpm

pnpm nx bundle <project-name>

yarn

yarn nx bundle <project-name>

npm

npx nx bundle <project-name>

bun

bunx nx bundle <project-name>

La configuration de Rolldown se trouve dans rolldown.config.ts, avec une entrée par bundle à générer. Rolldown gère la création de plusieurs bundles en parallèle si définis.

Configuration personnalisée

Vous pouvez ajuster la configuration de Rolldown dans rolldown.config.ts, par exemple si vous avez des dépendances qui reposent sur des chemins de fichiers et ne peuvent pas être regroupées, vous pouvez les ajouter à la liste des modules external.

La cible de bundle utilise http.ts comme point d’entrée pour le serveur MCP HTTP Streamable à héberger sur Bedrock AgentCore Runtime.

Cible Docker

Le générateur configure une cible <your-server-name>-docker qui copie le Dockerfile depuis le répertoire source de votre serveur MCP vers le répertoire de sortie du bundle. Cela co-localise le Dockerfile avec les artefacts bundlés, permettant à CDK de construire l’image Docker directement en utilisant AgentRuntimeArtifact.fromAsset.

Une cible docker est aussi générée pour préparer le contexte Docker de tous les serveurs MCP si vous en avez plusieurs définis.

Analyse d’image

L’image Docker construite pour ce projet est analysée pour détecter les vulnérabilités dans le cadre de la construction en utilisant Trivy, exécuté à partir de l’image Trivy hébergée sur ECR.

Une cible trivy est ajoutée à votre projet qui analyse l’image construite et fait échouer la construction si une vulnérabilité de gravité HIGH ou CRITICAL est trouvée. Le Dockerfile généré utilise une image de base sans vulnérabilité corrigeable connue de ces gravités au moment de la génération, et met à niveau les outils intégrés (tels que npm) pour le maintenir ainsi.

L’analyse utilise le même moteur de conteneur que votre construction d’image (docker ou finch), donc aucun outillage supplémentaire n’est requis. Étant donné que l’analyse n’est réexécutée que lorsque l’image change, une image inchangée n’est pas réanalysée.

Les vulnérabilités non corrigeables sont ignorées

L’analyse s’exécute avec --ignore-unfixed, donc les vulnérabilités sans correctif disponible ne font pas échouer la construction, car elles ne peuvent pas être corrigées en mettant à niveau les outils dans votre Dockerfile — elles ne sont pas signalées dans la sortie d’analyse de la construction. Au fur et à mesure que de nouvelles vulnérabilités sont divulguées, le résultat des analyses peut changer au fil du temps, donc examinez l’image périodiquement en exécutant trivy image <your-image> sans le flag, et reconstruisez avec une image de base plus récente (ou ajoutez des étapes de conteneur pour appliquer les correctifs disponibles) une fois qu’un correctif est publié.

Suppression des résultats Trivy

Il peut y avoir des cas où vous souhaitez supprimer une vulnérabilité spécifique, par exemple lorsqu’aucun correctif n’est encore disponible et que vous avez évalué le risque comme acceptable.

Ajoutez l’ID de vulnérabilité (un par ligne) au fichier .trivyignore à la racine de votre projet :

.trivyignore

# node-tar arbitrary file write - not exploitable in our usage
CVE-2024-XXXXX

Pour plus de détails sur le filtrage des résultats, consultez la documentation de filtrage Trivy.

Observabilité

Votre serveur MCP est automatiquement configuré avec de l’observabilité grâce à AWS Distro for Open Telemetry (ADOT), en configurant l’auto-instrumentation dans votre Dockerfile.

Vous pouvez trouver les traces dans la console AWS CloudWatch en sélectionnant “GenAI Observability” dans le menu. Notez que pour que les traces soient peuplées, vous devrez activer Transaction Search.

Pour plus de détails, consultez la documentation d’AgentCore sur l’observabilité.

Connexions

Utilisez le générateur connection pour intégrer ce projet avec d’autres dans votre espace de travail. Les connexions suivantes impliquent ce projet :

TypeScript Agent vers MCPConnecter un TypeScript Agent à un serveur MCP

Python Agent vers MCPConnecter un Python Agent à un serveur MCP

Serveur MCP vers Base de données relationnelleConnecter un serveur MCP TypeScript à une base de données relationnelle Aurora

Serveur MCP vers TypeScript DynamoDBConnecter un serveur MCP TypeScript à une table DynamoDB

AgentCore Gateway vers Serveur MCPAgréger un serveur MCP derrière une AgentCore Gateway