techn

logies

techn

logies

techn

logies

4 sept. 2025

IA

MCP et Cursor : quand l'IA automatise nos outils de développement

IA

MCP et Cursor : quand l'IA automatise nos outils de développement

Fin 2024, Anthropic lance le Model Context Protocol (MCP), un protocole ouvert qui permet aux modèles d'IA de communiquer directement avec des outils (et notamment les solutions de développement). Rapidement adoptés par Cursor, les MCP transforment la façon de travailler en automatisant des tâches répétitives comme la création de collections Postman ou la configuration d'environnements AWS. Mais concrètement, comment ça marche et pourquoi devriez-vous vous y intéresser ?

Quand l'IA discute avec nos outils de développement

Le Model Context Protocol (MCP) est un protocole standard ouvert qui permet aux modèles d'IA de communiquer avec des outils et des données externes. 

Concrètement, il agit comme un "traducteur" entre l'intelligence artificielle et des applications.

L'architecture MCP repose sur un système client-serveur simple : 

  • Le client, c'est l'IA (dans notre cas, Cursor)

  • Le serveur, ce sont nos outils (Postman, AWS, JIRA, etc.)

  • Le protocole standardise la communication entre les deux

Cursor a choisi MCP pour plusieurs raisons : 

  • La simplicité : un seul protocole pour tous les outils

  • La flexibilité : possibilité d'ajouter facilement de nouveaux services

  • Standard ouvert : pas de dépendance à un fournisseur spécifique

L'installation et la configuration en 5 minutes chrono

Pour installer un des MCP les plus courants sur Cursor, direction la documentation officielle : https://docs.cursor.com/en/tools/mcp.

Un simple clic sur "+ Add to Cursor" et le MCP s'ajoute automatiquement dans votre éditeur, modifiant directement le fichier mcp.json. C'est aussi simple que ça.

Après l’installation du MCP, il faut le configurer avec les différentes informations dont il a besoin pour fonctionner. Par exemple pour Postman, il faut modifier le fichier mcp.json pour y ajouter votre clé API personnelle, clé qui se génère ou se trouve dans les paramètres de votre compte Postman.

On peut également configurer les outils que Cursor peut utiliser. Dans le cas de Postman, cela lui permet de restreindre son comportement pour qu’il ne puisse rien ajouter ou supprimer sans notre autorisation

Il est également possible de configurer des variables d’environnements qui seront utilisées par le MCP.

AWS, par exemple, utilise par défaut les variables d'environnement suivantes : 

  • FASTMCP_LOG_LEVEL 

  • AWS_DOCUMENTATION_PARTITION

Le serveur MCP AWS officiel (https://github.com/awslabs/mcp) propose plusieurs serveurs spécialisés (Terraform, EKS, Serverless, etc…). 

Selon le serveur que vous souhaitez utiliser, il est recommandé de consulter la documentation spécifique disponible dans le README de chaque serveur pour connaître les paramètres exacts et les prérequis.

L'avantage de cette approche ? Il est également possible d'ajouter des MCP personnalisés de cette manière avec vos propres paramètres. Vous pouvez ainsi créer des serveurs MCP sur mesure pour vos outils internes ou des services spécifiques à votre projet.

Postman et MCP, le cas d'usage idéal

L’un des usages les plus convaincants de l’intégration entre MCP et Postman, c’est la création automatisée de collections à partir de simples instructions. Plus besoin de passer du temps à tout configurer à la main : il suffit de décrire ce que l’on veut, et Cursor s’occupe du reste.

Sur la première capture, on voit la demande utilisateur : créer une collection Postman nommée "CursorTest" avec deux routes, /login et /logout. Cursor détaille alors chaque étape : identification de l’utilisateur, sélection du bon workspace, puis création de la collection.

La seconde capture montre le résultat : la collection "CursorTest" est générée avec les routes demandées, toutes les informations nécessaires (méthodes, headers, variables d’environnement) sont déjà prêtes à l’emploi. Il ne reste plus qu’à modifier l’URL de base ou à utiliser les endpoints, sans avoir à écrire la moindre requête manuellement.

Il est également possible d’aller plus loin : en fournissant à Cursor le contexte d’un fichier (par exemple un fichier de routes NestJS), on peut lui demander de générer automatiquement toute la collection Postman pour interagir avec l’application correspondante. Cela permet de gagner encore plus de temps et d’éviter les oublis ou erreurs de configuration. En quelques secondes, on obtient une collection complète, directement exploitable pour tester ou documenter une API.

Au final, cette automatisation fait gagner un temps précieux et réduit les risques d’erreurs : en quelques clics, la base de travail est prête, adaptée à l’environnement de chacun.

Création d’un MCP : comment faire ?

La création d’un MCP repose essentiellement sur la structuration d’un objet, généralement en JSON, qui définit précisément le contexte qui sera envoyé à un modèle d’IA. Dans notre exemple, nous allons créer un serveur MCP de communication avec une API de gestion de produits en Node et TypeScript que nous allons connecter à Cursor : 

Tout d’abord on initialise un projet npm : 

mkdir product-mcp-server
cd product-mcp-server
npm init -y

On vient installer les dépendances de base : 

npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node

On créé la structure de base de fichiers : 

touch tsconfig.json
mkdir src
touch src/index.ts

On vient mettre à jour le fichier tsconfig.json avec le code suivant :

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

On vient ensuite mettre à jour le package.json. A savoir que le property dans le champ “bin” est totalement personnalisable, c’est la commande que l’on veut exposer globalement. On pourrait très bien mettre “product-mcp” au lieu de “product-mcp-server” : 

{
  "name": "product-mcp-server",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "type": "module",
  "bin": {
    "product-mcp-server": "./build/index.js"
  },
  "scripts": {
    "build": "tsc && chmod 755 build/index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.17.5",
    "zod": "^3.25.76"
  },
  "devDependencies": {
    "@types/node": "^24.3.0",
    "typescript": "^5.9.2"
  },
  "files": [
    "build"
  ]
}

Les fichiers de base du MCP sont créé. Maintenant, on va s’attaquer à la logique et aux outils disponibles. Il va y en avoir 3 :

  • Nom de l’outil : login

  • Paramètres : 

    • username : string

    • password : string

  • Nom de l’outil : add_product

  • Paramètres :

    • name : string

    • description : string

    • price : number

    • stock : number

  • Nom de l’outil : delete_product

  • Paramètres : 

    • productId: string

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
// MCP Server instance creation
const server = new McpServer({
  name: "product-management",
  version: "1.0.0",
  capabilities: {
    resources: {},
    tools: {},
  },
});
// MCP Tools definition (ex: login, addProduct, deleteProduct)
server.tool(
  "login",
  "User login",
  {
    username: z.string(),
    password: z.string(),
  },
  async ({ username, password }) => {
    // Authentication logic (mock for example)
    if (username === "admin" && password === "password123") {
      return {
        content: [
          { type: "text", text: "Login successful! Token: xyz123" }
        ],
      };
    }
    return {
      content: [
        { type: "text", text: "Invalid username or password." }
      ],
    };
  }
);
server.tool(
  "add_product",
  "Add a new product",
  {
    name: z.string(),
    description: z.string(),
    price: z.number(),
    stock: z.number(),
  },
  async ({ name, description, price, stock }) => {
    // Product addition logic (mock for example)
    const productId = Math.floor(Math.random() * 100000).toString();
    return {
      content: [
        { type: "text", text: `Product '${name}' created with ID: ${productId}` }
      ],
    };
  }
);
server.tool(
  "delete_product",
  "Delete a product",
  {
    productId: z.string(),
  },
  async ({ productId }) => {
    // Product deletion logic (mock for example)
    return {
      content: [
        { type: "text", text: `Product ${productId} deleted.` }
      ],
    };
  }
);
// MCP Server launch on STDIO
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Product Management MCP Server running on stdio");
}
main().catch((error) => {
  console.error("Fatal error in main():", error);
  process.exit(1);
});

On vient ensuite compiler le projet : 

npm run build

Pour finir on vient lancer le serveur MCP : 

node build/index.js

Notre serveur MCP est lancé. Il ne manque plus que la connexion à Cursor à définir dans sa configuration : 

{
  "mcpServers": {
    "product-mcp-server": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/YOUR/PROJECT/build/index.js"],
      "env": {
        // Optional environments variables
      }
    }
  }
}

En conclusion : l’automatisation au services des devs

L’intégration entre MCP et Postman, orchestrée par Cursor, montre à quel point l’automatisation peut transformer le quotidien des développeurs. Moins de tâches manuelles, moins d’erreurs, et surtout plus de temps pour se concentrer sur ce qui compte vraiment. En fluidifiant les process et en centralisant la configuration, les MCP s’imposent comme de précieux alliés pour rendre le travail des équipes tech plus simple, plus rapide et plus fiable.

Envie d'en savoir plus ?

Un avis à partager, un projet, une question...