stdio

Proxies comunicação STDIN/STDOUT/STDERR com executáveis locais. Este comando é particularmente útil para testar e depurar servidores do Model Context Protocol (MCP) e outras aplicações baseadas em STDIO.

Sinopse

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

Description

O stdio comando inicia um processo filho e faz proxies para toda a comunicação STDIN/STDOUT/STDERR. Isto permite-lhe:

• Inspecionar mensagens que fluem entre clientes (como o VS Code) e servidores MCP
• Respostas simuladas para testar o comportamento do cliente sem correr lógica real do servidor
• Problemas de comunicação de depuração usando o Chrome DevTools
• Gestão de erros de teste através da injeção de respostas simuladas ou pedidos de bloqueio
• Simular latência na comunicação STDIO

Usage

devproxy stdio npx -y @modelcontextprotocol/server-filesystem

Arguments

Nome	Description	Obrigatório
<command>	O comando para executar	yes
[args...]	Argumentos a passar ao comando	no

Opções

Nome	Description	Valores permitidos	Predefinido
-c, --config-file <configFile>	O caminho para o arquivo de configuração	Caminho do arquivo local	devproxyrc.json
--no-stdio-mocks	Desativar o carregamento das respostas simuladas STDIO	não aplicável	não aplicável
--stdio-mocks-file <file>	Caminho para o ficheiro que contém respostas simuladas STDIO	Caminho do arquivo local	-
--log-level <loglevel>	Nível de mensagens a registar	trace, debug, information, warning, error	information
-?, -h, --help	Mostrar ajuda e informação de utilização	não aplicável	não aplicável

Examples

Inicie um servidor MCP com Dev Proxy

devproxy stdio npx -y @modelcontextprotocol/server-filesystem

Especificar um ficheiro de configuração personalizado

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

Especificar um ficheiro de mocks personalizado

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

Desativar mocks stdio

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

Exemplo de configuração

Para usar o stdio comando com plugins, crie um ficheiro de configuração:

Ficheiro: 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"
  }
}

Plugins suportados

Os seguintes plugins suportam a interceção STDIO:

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

Architecture

Ao usar o stdio comando, o Dev Proxy atua como 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 plugins são invocados por ordem:

1. BeforeStdinAsync - Antes de encaminhar o stdin para a criança
2. AfterStdoutAsync - Após receber o período de reabilitação do filho
3. AfterStderrAsync - Após receber STDERR da criança

Integração com DevTools

Quando ativas o DevToolsPlugin, podes inspecionar o tráfego STDIO no Chrome DevTools:

• As mensagens aparecem com stdio://command-name URLs
• Pedidos apresentados como STDIN método
• As respostas aparecem como STDOUT (estado 200) ou STDERR (estado 500)
• Os corpos das mensagens são formatados como JSON quando aplicável

Próximo passo

Respostas simuladas STDIO para servidores MCP