Um gateway MCP fica entre seus agentes de IA e suas ferramentas, então escolher onde ele roda faz diferença. Esta comparação coloca lado a lado o Amazon Bedrock AgentCore Gateway, o Azure API Management e o MCP Gateway de código aberto da Microsoft, em autenticação, roteamento, custo e esforço de configuração.
Seu agente funciona bem com três ferramentas. Aí a equipe adiciona uma API de cobrança, um sistema de chamados, um índice de busca e alguns serviços internos, e cada cliente MCP acaba carregando as próprias URLs, as próprias credenciais e a própria ideia de requisição segura. Um gateway MCP resolve isso ao colocar um único endpoint controlado na frente de todas as ferramentas. A parte difícil é decidir onde ele vai morar. A AWS oferece um gateway gerenciado feito para agentes, o Azure estende um produto de gerenciamento de APIs que muitas equipes já usam, e as duas nuvens permitem hospedar um proxy por conta própria quando você quer controle total.
Esta comparação coloca lado a lado as opções reais: o que cada uma faz, como funciona a autenticação, como a cobrança é estruturada e os passos exatos para colocar uma no ar. Nomes de produtos, planos e limites mudam rápido, então os detalhes abaixo seguem a documentação dos fornecedores até outubro de 2026. Revise essa documentação antes de se comprometer com qualquer coisa.
Um gateway é um proxy reverso que fala o Model Context Protocol. Os clientes enviam mensagens JSON-RPC como tools/list e tools/call via Streamable HTTP, e o gateway decide quem pode chamar o quê, encaminha cada chamada ao backend certo e registra o que aconteceu. Seus agentes de IA nunca precisam saber se uma ferramenta está numa função Lambda, numa API REST ou num contêiner em outra região.
Sem um gateway, cada cliente MCP aponta direto para cada servidor MCP. Dez agentes e oito servidores significam oitenta conexões para configurar, proteger e monitorar. Com um gateway, os dez clientes falam com um único endpoint, e o gateway distribui as chamadas para os servidores por trás dele. Trocar um backend passa a ser uma mudança no gateway, e não uma atualização em todos os clientes.
tools/list.💡 Dica: Pergunte quem chama cada ferramenta e com que frequência. Se a resposta honesta for "um desenvolvedor, localmente", um gateway é prematuro. Quando aparecer uma segunda equipe ou um cliente externo, ele deixa de ser opcional.
O Amazon Bedrock AgentCore chegou à disponibilidade geral em outubro de 2025, e o AgentCore Gateway é o ponto de entrada para o tráfego de agentes. Um gateway tem um ou mais destinos em três categorias:
tools/list consolidado.model na requisição escolhe o destino.Todo gateway precisa de um autorizador de entrada. As opções são OAuth com JWT, IAM com AWS Signature Version 4, um modo "apenas autenticar" que valida tokens e deixa a autorização a cargo do destino, e nenhuma autorização para desenvolvimento. Em produção, use uma das duas primeiras.
Para destinos MCP, a AWS lista vários tipos de origem:
As chamadas de saída para destinos OpenAPI e MCP passam por provedores de credenciais, que podem armazenar credenciais de API ou configurações OAuth, assinar com SigV4 ou dispensar autenticação para endpoints públicos. Destinos Lambda e Smithy usam a função de execução que você anexa. Dois recursos extras importam em escala: a busca semântica de ferramentas, que ajuda um agente a encontrar a ferramenta certa entre centenas, e a sincronização de capacidades para destinos MCP.
Algumas equipes dispensam a opção gerenciada e rodam um proxy MCP de código aberto no ECS ou no EKS, atrás de um Application Load Balancer. Você fica responsável por escalonamento, atualizações de segurança, validação de tokens e registro de logs, mas também ganha roteamento personalizado, uma base de código que pode reutilizar em qualquer nuvem e nenhuma dependência da lista de recursos de um único fornecedor. Isso serve a equipes de plataforma com experiência em Kubernetes e vira um hábito caro para todas as outras.
O Azure API Management (APIM) oferece duas formas nativas de publicar servidores MCP:
A governança passa pelo mecanismo de políticas. As políticas hoje se aplicam a todas as operações expostas como ferramentas em um determinado servidor MCP, e a Microsoft lista limitação de taxa e cotas, validação de JWT com o Microsoft Entra ID ou outro provedor de identidade, filtragem por IP e cache de respostas. O tráfego aparece no Azure Monitor e no Application Insights, e o Azure API Center pode funcionar como um registro privado para que as equipes encontrem os servidores que existem. Tudo também pode ser gerenciado como código com Bicep, Terraform, Azure CLI ou templates ARM.
A disponibilidade é ampla: os níveis clássicos Developer, Basic, Standard e Premium, os níveis v2 (Basic v2, Standard v2, Premium v2) e o gateway autogerenciado para a sua própria infraestrutura. Dois limites importam. O APIM oferece suporte apenas a ferramentas MCP, sem recursos nem prompts, e os recursos de MCP não estão disponíveis em workspaces.
Separado do APIM, o repositório microsoft/mcp-gateway no GitHub é uma camada de proxy reverso e gerenciamento para servidores MCP no Kubernetes. Seu plano de dados usa roteamento com estado e ciente de sessão, então requisições que compartilham um ID de sessão chegam à mesma instância do servidor, e seu plano de controle implanta, atualiza e remove adaptadores de servidor. A autorização depende de funções do Entra ID, e o repositório traz caminhos de implantação em PowerShell e Bicep para o AKS, com Azure Container Registry e Cosmos DB.
💡 Mudança na especificação: A revisão 2026-07-28 da especificação MCP removeu as sessões do protocolo, eliminando o handshake de initialize e o cabeçalho
Mcp-Session-Id. A afinidade de sessão ainda importa para servidores em revisões antigas ou para servidores que guardam estado na memória, mas os novos servidores não precisam mais dela.
Os exemplos da própria Microsoft de servidores existentes atrás do APIM são LangChain, LangServe, Logic Apps e Functions. Qualquer servidor compatível com MCP que o APIM consiga alcançar por HTTP é um candidato, o que torna o gateway um wrapper útil para um parque misto de servidores antigos e novos.
| Recurso | AgentCore Gateway | API Management | Microsoft MCP Gateway |
|---|---|---|---|
| Modelo | Serviço gerenciado da AWS | Serviço gerenciado do Azure, ou gateway autogerenciado | Código aberto, você executa no Kubernetes |
| Fontes de ferramentas | Lambda, API Gateway REST, OpenAPI, Smithy, servidores MCP | APIs REST no APIM, servidores MCP existentes | Servidores MCP que você implanta no cluster |
| Recursos MCP | Ferramentas, prompts, recursos | Apenas ferramentas | Depende dos seus servidores |
| Autenticação de entrada | OAuth (JWT), IAM SigV4, apenas autenticar | JWT do Entra ID ou de outros provedores, mais outros métodos | Autorização por funções do Entra ID |
| Cobrança | Por operação MCP, consulta de busca e ferramenta indexada | Por nível e unidades de escala | Recursos de AKS, registro e Cosmos DB que você executa |
| Carga operacional | Baixa | Baixa a média | Alta |
| Melhor uso | Equipes com foco na AWS, muitas fontes de ferramentas mistas | Equipes que já usam o APIM para REST | Equipes de plataforma no Kubernetes |
Identidade. As duas opções gerenciadas validam JWTs, e o APIM aceita explicitamente tokens do Entra ID ou de outros provedores de identidade. O AgentCore acrescenta SigV4 para chamadores que já têm credenciais da AWS, o que é útil no tráfego entre serviços. Seja qual for sua escolha, teste como o gateway responde a uma chamada sem autenticação. O modelo de autorização do MCP é construído sobre OAuth, e um 401 limpo que aponta os clientes para o servidor de autorização certo é o que permite que eles façam login sem configuração escrita à mão.
Cobrança. O AgentCore Gateway cobra pelas chamadas que seus agentes fazem por ele, contadas como operações MCP como ListTools, CallTool e Ping, além de consultas de busca e ferramentas indexadas para busca semântica. O APIM tem preço por nível e unidades de escala, então sua conta acompanha a capacidade, e não as chamadas. O gateway da Microsoft é de código aberto, mas você paga pelo cluster, pelo registro, pelo banco de dados e pelas pessoas que o mantêm atualizado. Tráfego irregular e de baixo volume tende a favorecer o preço por operação, enquanto tráfego intenso e constante tende a favorecer a capacidade fixa. Consulte a página de preços de cada fornecedor para os valores atuais.
💡 Dica: Como ListTools e Ping contam como operações cobráveis no AgentCore, clientes que fazem muitas chamadas e atualizam a lista de ferramentas a cada turno aumentam a conta. Guarde a lista em cache no cliente por alguns minutos.
Os dois caminhos são rápidos para uma primeira ferramenta se seu backend já existir. Os passos abaixo ficam no nível que a documentação garante, então confira os rótulos do console e as flags da CLI com a documentação atual.
tools/list e confirme que todas as ferramentas esperadas aparecem, e que nenhuma outra aparece.Uma política inicial tem esta aparência:
<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401"
failed-validation-error-message="Unauthorized">
<openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
<audiences>
<audience>api://mcp-gateway</audience>
</audiences>
</validate-jwt>
<rate-limit calls="60" renewal-period="60" />
</inbound>
A mesma requisição funciona em qualquer um dos gateways, o que a torna uma forma justa de comparação:
curl -X POST "$GATEWAY_URL" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Servidores em revisões antigas da especificação podem esperar uma chamada initialize primeiro e, depois, um cabeçalho Mcp-Session-Id, enquanto um servidor na revisão 2026-07-28 não espera. Para qualquer coisa além de um teste rápido, aponte o MCP Inspector para o gateway e execute uma chamada real de ferramenta, porque uma requisição isolada não mostra como as respostas em streaming se comportam.
Qualquer que seja a escolha, direcione a telemetria do gateway para os painéis que sua equipe já acompanha antes do primeiro agente entrar no ar. Volume de chamadas de ferramentas, taxas de erro e latência por ferramenta mostram o que os agentes realmente usam e quais das suas 200 operações ninguém chama.
Escolha-o quando suas ferramentas forem funções Lambda, APIs REST do API Gateway ou especificações OpenAPI, quando você quiser um único endpoint gerenciado que as agregue, e quando IAM ou OAuth já governarem seus chamadores. Também serve a equipes que querem busca semântica de ferramentas sem precisar construí-la, e a servidores que dependem de prompts e recursos.
Escolha-o quando suas APIs REST já estiverem no APIM, sua identidade for o Entra ID e sua equipe de plataforma conhecer o mecanismo de políticas. Você ganha limites de taxa, cotas, cache e monitoramento em que já confia. Escolha o gateway de código aberto da Microsoft apenas quando quiser controle em nível de Kubernetes e puder arcar com a operação.
Rodando nas duas nuvens? O AgentCore pode agregar servidores MCP remotos, e o APIM pode ficar na frente de servidores que alcança por HTTP, então um gateway em uma nuvem pode ficar na frente de ferramentas da outra. Isso funciona, mas adiciona latência, cobranças de saída de dados e um segundo sistema de identidade para conciliar. Na prática, um gateway por nuvem com um provedor de identidade compartilhado costuma ser mais simples do que um único gateway esticado entre as duas.
💡 Verificação rápida: Conte suas fontes de ferramentas, depois seu provedor de identidade e, por último, o formato do seu tráfego. Principalmente Lambda e OpenAPI apontam para o AgentCore. Principalmente REST já no APIM aponta para o API Management. Uma equipe de plataforma em Kubernetes que precise de controle rígido aponta para a opção autogerenciada.
Um gateway MCP é infraestrutura de base, e a boa infraestrutura é a parte que ninguém vê. O mesmo vale para os serviços que seus agentes chamam. O PicassoIA, por exemplo, expõe uma API para desenvolvedores em api.picassoia.com/v1 com autenticação por bearer token, tarefas assíncronas que você cria e depois consulta, e um limite de 5 predições simultâneas por conta, que as conexões de API e MCP compartilham. Esse tipo de teto é exatamente o que um gateway deve impor para você: enfileirar ou limitar a taxa do seu lado, em vez de deixar os agentes acumularem recusas.
Modelos de linguagem também ajudam na configuração. Você pode rascunhar Bicep, Terraform ou uma especificação OpenAPI para o seu gateway com o Claude Sonnet 5, revisar uma política com o GPT 5.6 Sol ou resumir rapidamente um changelog longo de fornecedor com o Gemini 3.5 Flash. Trate a saída deles como um primeiro rascunho e passe pela mesma revisão que daria ao pull request de um colega.
Depois, vêm as imagens. Textos de arquitetura, wikis internas e posts de lançamento ficam melhores com uma foto de capa forte. Abra o Picasso IA, escolha um modelo de texto para imagem como o Seedream 4.5, descreva a cena que você quer em algumas frases e gere várias variações. Troque a lente, a luz ou o cenário e compare. Sua primeira imagem não será a melhor, e a quinta costuma ser. Veja todos os modelos em picassoia.com/en/all-models e crie suas próprias imagens hoje.
Escolha seu idioma
