Guia pré-uso do MCP Gateway: agregar vários servidores MCP e APIs REST em uma superfície fixa de ferramentas (licença não comercial)

Se você conecta vários servidores MCP e APIs REST ao mesmo cliente de IA, logo percebe que são as próprias definições de ferramentas que enchem o contexto. A abordagem do MCP Gateway é colocar um único binário Rust entre o cliente e todas as suas ferramentas: os backends ficam atrás dele, e o agente vê uma metasuperfície compacta de 14 a 16 ferramentas em vez da definição completa de cada backend. Quanto mais definições de ferramentas ocupam o contexto, menos orçamento sobra para a tarefa real; condensá-las em uma superfície fixa e pequena é exatamente o problema que ele quer resolver. Antes de começar, confirme uma premissa: ele é distribuído por padrão sob uma licença não comercial; o uso pessoal e não comercial (incluindo rodar o gateway completo) é gratuito, e a operação comercial exige uma licença comercial.

Para quem é

• Para quem já conecta — ou planeja conectar — vários servidores MCP e APIs REST e quer que o tamanho da lista de ferramentas se mantenha estável: não importa quantos backends fiquem atrás, o agente enfrenta um conjunto pequeno e fixo de metaferramentas, e não a soma de todas as definições de backend.
• Para quem consegue manter um serviço residente na própria máquina: o gateway roda como um serviço HTTP local e os clientes se conectam a ele por um endpoint local.
• Não indicado para uso direto em ambientes comerciais: a operação comercial exige uma licença comercial, uma premissa que precisa estar resolvida antes da adoção; apenas um pequeno núcleo MIT de blocos genéricos é disponibilizado sob a licença MIT.
• Com poucos backends e uma lista de ferramentas já curta, o valor da agregação é limitado; as evidências não trazem dados comparativos sobre ganhos concretos em cenários pequenos.
• A lista de clientes suportados, a implantação remota e os métodos de autenticação não aparecem nas evidências: são pontos não confirmados; não assuma por conta própria.

Primeira tentativa em 3 minutos

• Pré-requisito: um ambiente com Homebrew disponível. O ponto de entrada oficial de instalação é um tap do Homebrew; as evidências não trazem outros métodos de instalação.
• Execute, na ordem, os três comandos do caminho oficial:

brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run

• O setup wizard do segundo passo importa seus servidores existentes e conecta os clientes. Atenção: isso é uma escrita de estado local — ele reescreve a configuração local do gateway e dos clientes, não é uma operação somente leitura; exatamente quais arquivos ele escreve e como os salva, as evidências não detalham item a item.
• Depois de iniciar o terceiro passo, o gateway roda como um serviço HTTP local. Do lado do cliente, conecte-se conforme o trecho de configuração oficial. O trecho declara um serviço chamado gateway do tipo http, apontando para o caminho /mcp na porta local 39400:

{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}

• Sinal de sucesso: quando o cliente se conecta a http://localhost:39400/mcp, a lista de ferramentas se condensa em um conjunto pequeno e fixo; nesse momento, chame uma vez o gateway_search_tools — a descrição oficial o apresenta como o buscador de ferramentas de backend — e se a busca retornar ferramentas dos backends que você conectou, o caminho do cliente ao gateway está funcionando. As evidências não informam se essa ferramenta carrega um readOnlyHint, então seu caráter de somente leitura não está confirmado; limite a primeira tentativa à busca e não execute ações de escrita. Nesse ponto, o agente carrega um conjunto pequeno e fixo de metaferramentas, e não todas as definições de backend.

Casos de uso

• Caso 1: colocar uma pilha de ferramentas multi-servidor em dieta. Situação: o cliente já tem vários servidores MCP conectados e as definições de cada backend consomem contexto. Como fazer: entregue seus servidores existentes ao assistente para importação e mantenha no cliente apenas http://localhost:39400/mcp como único endpoint. Resultado esperado: a superfície de ferramentas do agente fica fixa em torno de 14 a 16 ferramentas, e não a soma de todas as definições de backend; quando precisar de uma capacidade específica, localize-a primeiro com gateway_search_tools. Critério de julgamento: se o número de ferramentas exibido pelo cliente é claramente menor que o total de ferramentas dos backends conectados.
• Caso 2: buscar e depois invocar uma vez uma ferramenta real. Situação: você quer executar uma capacidade oferecida por um backend conectado (um servidor MCP ou uma API REST). Como fazer: localize primeiro a ferramenta alvo com gateway_search_tools e depois a invoque com gateway_invoke; o uso descrito oficialmente são justamente essas duas metaferramentas, buscar e invocar. Resultado esperado: a chamada é encaminhada ao backend correspondente e devolve o resultado dele; a saída concreta depende de quais backends você conectou, e as evidências não trazem uma saída de exemplo fixa. Se a busca não encontrar a ferramenta esperada, confirme primeiro se esse backend foi importado pelo assistente e repita a busca.

Limites de uso

• Licença e restrições: o uso pessoal e não comercial é gratuito, incluindo rodar o gateway completo; a operação comercial exige uma licença comercial; apenas um pequeno núcleo MIT de blocos genéricos é aberto sob MIT. Este ponto decide se você pode usar e em que escopo, e vem antes de qualquer outro julgamento.
• Natureza de leitura/escrita e efeitos colaterais: o gateway em si é um serviço local residente; o assistente escreve a configuração local; o gateway_invoke realmente aciona as ferramentas do backend, e seus efeitos colaterais dependem do backend invocado — antes de executar, confirme a natureza da operação alvo e seus pontos de confirmação.
• Dependências: a instalação depende do Homebrew; conectar os servidores existentes é feito pela importação do assistente.
• Pontos não confirmados: a lista de clientes suportados, o formato de configuração concreto para conectar APIs REST, a implantação além de localhost, os mecanismos de autenticação e se cada metaferramenta traz um readOnlyHint — nada disso é explicado nas evidências. Também não se explica se o gateway em si tem controle de acesso nem como registra os logs. Ausência de documentação não é ausência de risco; antes de adotar, tome como referência a documentação atual do repositório oficial.