stdio

Communication entre proxys STDIN/STDOUT/STDERR avec des exécutables locaux. Cette commande est particulièrement utile pour tester et déboguer des serveurs MCP (Model Context Protocol) et d’autres applications STDIO.

Synopsis

devproxy stdio [options] <command> [args...]

Descriptif

La stdio commande démarre un processus enfant et proxies toutes les communications STDIN/STDOUT/STDERR. Vous pouvez ainsi :

• Inspecter les messages qui circulent entre les clients (comme VS Code) et les serveurs MCP
• Simuler des réponses pour tester le comportement du client sans exécuter une logique serveur réelle
• Déboguer les problèmes de communication à l’aide de Chrome DevTools
• Tester la gestion des erreurs en injectant des réponses fictives ou en bloquant des demandes
• Simuler la latence sur la communication STDIO

Usage

devproxy stdio npx -y @modelcontextprotocol/server-filesystem

Arguments

Nom	Descriptif	Obligatoire
<command>	Commande à exécuter	oui
[args...]	Arguments à passer à la commande	Non

Options

Nom	Descriptif	Valeurs autorisées	Par défaut
-c, --config-file <configFile>	Le chemin d’accès au fichier de configuration	Chemin de fichier local	devproxyrc.json
--no-stdio-mocks	Désactiver le chargement des réponses fictives STDIO	n/a	n/a
--stdio-mocks-file <file>	Chemin d’accès au fichier contenant des réponses fictives STDIO	Chemin de fichier local	-
--log-level <loglevel>	Niveau de messages à journaliser	trace, debug, , information, warning, error	information
-?, -h, --help	Afficher les informations d’aide et d’utilisation	n/a	n/a

Examples

Démarrer un serveur MCP avec le proxy de développement

devproxy stdio npx -y @modelcontextprotocol/server-filesystem

Spécifier un fichier de configuration personnalisé

devproxy stdio --config-file ./my-config.json npx my-server

Spécifier un fichier fictif personnalisé

devproxy stdio --stdio-mocks-file ./my-mocks.json npx my-server

Désactiver les fictives stdio

devproxy stdio --no-stdio-mocks npx my-server

Exemple de configuration

Pour utiliser la stdio commande avec des plug-ins, créez un fichier de configuration :

Fichier : devproxyrc.json

{
  "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v2.1.0/rc.schema.json",
  "plugins": [
    {
      "name": "MockStdioResponsePlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "mockStdioResponsePlugin"
    },
    {
      "name": "DevToolsPlugin",
      "enabled": true,
      "pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
      "configSection": "devTools"
    }
  ],
  "devTools": {
    "preferredBrowser": "Edge"
  },
  "mockStdioResponsePlugin": {
    "mocksFile": "stdio-mocks.json"
  }
}

Plug-ins pris en charge

Les plug-ins suivants prennent en charge l’interception STDIO :

Plug-in	Descriptif
MockStdioResponsePlugin	Simuler les réponses STDIN/STDOUT/STDERR
DevToolsPlugin	Inspecter le trafic STDIO dans Chrome DevTools
LatencePlugin	Ajouter une latence artificielle à la communication STDIO

Architecture

Lorsque vous utilisez la stdio commande, le proxy de développement agit comme intermédiaire entre le processus parent (tel que VS Code) et le processus enfant (tel qu’un serveur MCP) :

┌─────────────────┐     STDIN      ┌──────────────────┐     STDIN      ┌─────────────────┐
│  Parent Process │ ─────────────▶ │   Dev Proxy      │ ─────────────▶ │  Child Process  │
│   (VS Code)     │                │                  │                │   (MCP Server)  │
│                 │ ◀───────────── │  ┌────────────┐  │ ◀───────────── │                 │
└─────────────────┘    STDOUT      │  │  Plugins   │  │    STDOUT      └─────────────────┘
                                   │  └────────────┘  │
                                   └──────────────────┘

Les plug-ins sont appelés dans l’ordre :

1. BeforeStdinAsync - Avant de transférer la stdin à l’enfant
2. AfterStdoutAsync - Après avoir reçu stdout de l’enfant
3. AfterStderrAsync - Après avoir reçu stderr de l’enfant

Intégration de DevTools

Lorsque vous activez DevToolsPlugin, vous pouvez inspecter le trafic STDIO dans Chrome DevTools :

• Les messages s’affichent avec stdio://command-name des URL
• Les requêtes s’affichent en tant que STDIN méthode
• Les réponses s’affichent en tant que STDOUT (état 200) ou STDERR (état 500)
• Les corps de message sont mis en forme au format JSON le cas échéant

Étape suivante

Simuler des réponses STDIO pour les serveurs MCP