stdio

Proxies STDIN/STDOUT/STDERR comunicação com executáveis locais. Esse comando é particularmente útil para testar e depurar servidores MCP (Model Context Protocol) e outros aplicativos baseados em STDIO.

Sinopse

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

Description

O stdio comando inicia um processo filho e faz proxies de toda a comunicação STDIN/STDOUT/STDERR. Isso permite que você:

• Inspecionar mensagens que fluem entre clientes (como o VS Code) e servidores MCP
• Respostas simuladas para testar o comportamento do cliente sem executar a lógica real do servidor
• Depurar problemas de comunicação usando o Chrome DevTools
• Testar o tratamento de erros injetando respostas simuladas ou bloqueando solicitações
• Simular latência na comunicação STDIO

Usage

devproxy stdio npx -y @modelcontextprotocol/server-filesystem

Arguments

Nome	Description	Obrigatório
<command>	O comando a ser executado	sim
[args...]	Argumentos a serem passados para o comando	no

Opções

Nome	Description	Valores permitidos	Padrão
-c, --config-file <configFile>	O caminho para o arquivo de configuração	Caminho de arquivo local	devproxyrc.json
--no-stdio-mocks	Desabilitar o carregamento de respostas simuladas do STDIO	n/a	n/a
--stdio-mocks-file <file>	Caminho para o arquivo que contém respostas simuladas de STDIO	Caminho de arquivo local	-
--log-level <loglevel>	Nível de mensagens para log	trace, debug, information, , warningerror	information
-?, -h, --help	Mostrar informações de ajuda e uso	n/a	n/a

Exemplos

Iniciar um servidor MCP com o Proxy de Desenvolvimento

devproxy stdio npx -y @modelcontextprotocol/server-filesystem

Especificar um arquivo de configuração personalizado

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

Especificar um arquivo de simulações personalizado

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

Desabilitar simulações de stdio

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

Exemplo de configuração

Para usar o stdio comando com plug-ins, crie um arquivo de configuração:

Arquivo: 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 com suporte

Os plug-ins a seguir dão suporte à interceptação STDIO:

Plug-in	Description
MockStdioResponsePlugin	Respostas STDIN/STDOUT/STDERR simuladas
DevToolsPlugin	Inspecionar o tráfego STDIO no Chrome DevTools
LatencyPlugin	Adicionar latência artificial à comunicação STDIO

Architecture

Ao usar o comando, o stdio Proxy de Desenvolvimento atua como um intermediário entre o processo pai (como o VS Code) e o processo filho (como um servidor MCP):

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

Os plug-ins são invocados na ordem:

1. BeforeStdinAsync - Antes de encaminhar stdin para filho
2. AfterStdoutAsync - Depois de receber stdout do filho
3. AfterStderrAsync - Depois de receber stderr do filho

Integração do DevTools

Ao habilitar o DevToolsPlugin, você pode inspecionar o tráfego STDIO no Chrome DevTools:

• As mensagens aparecem com stdio://command-name URLs
• Solicitações são mostradas como STDIN método
• As respostas são mostradas como STDOUT (200 status) ou STDERR (500 status)
• Os corpos de mensagem são formatados como JSON quando aplicável

Próxima etapa

Respostas STDIO simuladas para servidores MCP