O Padrão MCP Empresarial: Proxy, Agregação, Hospedagem

Resumo

• O catálogo awslabs/mcp cresceu de ~25 para 58 servidores em seis meses — carregar todos eles de forma ingênua consome ~200k tokens antes que uma pergunta seja digitada.
• Um proxy de divulgação progressiva reduz o início da sessão para ~2k tokens ao substituir todos os esquemas de ferramentas por duas meta-ferramentas: discover_tools e call_tool.
• Hospedar o proxy como um serviço HTTP compartilhado atrás de um gateway elimina a configuração por desenvolvedor, centraliza o IAM e dá visibilidade das chamadas de ferramentas para toda a equipe.
• O padrão de autenticação não requer chaves estáticas: identidade OIDC → STS AssumeRoleWithWebIdentity → JWT para o gateway → o papel de serviço do proxy realiza o trabalho na nuvem.
• Implante o proxy localmente primeiro, valide o roteamento de descoberta, depois containerize e conecte o gateway — o valor do catálogo é imediato; a infraestrutura compartilhada vem a seguir.

Existem 58 servidores MCP públicos no repositório awslabs/mcp — cada um uma interface focada em um serviço de nuvem: CloudWatch, ECS, CDK, DynamoDB, IAM, análise de custos, busca de documentação e mais 51. Eles são de código aberto, mantidos e se conectam diretamente a qualquer agente compatível com MCP via stdio.

A abordagem ingênua é adicionar todos eles ao seu arquivo de configuração e deixá-los carregar. Isso funciona em uma máquina pessoal para um subconjunto de servidores. Não funciona para uma equipe e não escala: mais de 50 servidores carregando no início da sessão consomem centenas de milhares de tokens antes que alguém digite uma pergunta. O padrão empresarial é diferente — proxy, agregar, hospedar.

Este post cobre os três passos.

Passo 1: O Proxy

O proxy de divulgação progressiva é a arquitetura local certa para um grande conjunto de ferramentas. Em vez de carregar todos os esquemas de ferramentas no contexto do agente no início da sessão, o proxy:

1. Cria cada servidor como um subprocesso na inicialização
2. Coleta todos os esquemas de ferramentas via o handshake initialize / tools/list
3. Constrói um índice de busca BM25 sobre todos os nomes de ferramentas, descrições e descrições de parâmetros
4. Expõe duas meta-ferramentas para o agente: discover_tools(query) e call_tool(name, arguments)
5. Carrega um pequeno conjunto sempre ativo de ferramentas de alta frequência incondicionalmente

O início da sessão vai de ~200k tokens para ~2k. O catálogo completo está disponível sob demanda. O agente chama discover_tools("verificar a saúde do serviço ECS"), recebe de volta os 3–5 esquemas de ferramentas mais relevantes e executa a partir daí.

Para o catálogo awslabs especificamente, o proxy agrega várias centenas de ferramentas em 58 servidores em uma única superfície descobrível. O agente não sabe nem se importa qual servidor possui qual ferramenta — ele chama call_tool("get_log_events", {...}) e o proxy direciona para o CloudWatch.

O que o Catálogo Abrange

Os 58 servidores se dividem em cinco categorias:

Infraestrutura e computação: ECS, EKS, Lambda, Step Functions, Serverless, IAM, redes, gerenciamento SAP, ferramentas de contêiner (Finch), IaC

Dados e armazenamento: DynamoDB, PostgreSQL, MySQL, Redshift, OpenSearch, DocumentDB, ElastiCache, Keyspaces (Cassandra), Neptune (gráfico), Aurora DSQL, Tabelas S3, Memcached, Valkey, Timestream para InfluxDB, Prometheus

Operações e observabilidade: CloudWatch, Sinais de Aplicação do CloudWatch, CloudTrail, custos e faturamento, wrapper completo da API AWS, Suporte AWS, revisão de segurança Well-Architected

Serviços de IA/ML: Recuperação de KB do Bedrock, AgentCore, SageMaker (incluindo ferramentas de Spark do Unified Studio), Translate, SNS/SQS, Q Business, Q Index, gerenciamento de conhecimento, carregamento de documentos, imagem de saúde, lago de saúde

Utilitários para desenvolvedores: Busca de documentação da AWS, CDK, geração de servidor OpenAPI, AppSync, preços, serviços de localização, IoT SiteWise, processamento de dados, Health Omics, Transform

O servidor de documentação sozinho muda como os agentes interagem com a documentação do serviço — search_documentation e read_documentation_page substituem as idas e vindas do navegador. O servidor CDK dá aos agentes acesso para construir APIs e exemplos de código durante o trabalho de infraestrutura. O servidor de custos e faturamento transforma perguntas de faturamento em consultas estruturadas.

O aws-api-mcp-server é o que abrange tudo: ele envolve toda a superfície da API do AWS CLI para serviços que ainda não têm um servidor dedicado. Cobertura ampla, menos ergonômica — mantenha-o atrás da descoberta em vez do conjunto sempre ativo.

O catálogo também ainda está crescendo. A contagem era em torno de 25 há seis meses. Hoje, com 58, e com o padrão de adições, provavelmente chegará a 80+ até o final do ano. Qualquer arquitetura que exija adicionar cada servidor manualmente às configurações dos desenvolvedores se torna um problema de manutenção rapidamente.

Passo 2: O Gateway

Executar mais de 50 subprocessos no laptop de um desenvolvedor é aceitável para indivíduos que usam seletivamente um subconjunto. Para uma equipe, é a arquitetura errada por três razões:

1. Fricção de configuração — cada desenvolvedor precisa de npx, a versão correta do Node, credenciais AWS configuradas, todos os servidores instalados. Superfície de integração não trivial, e cresce com cada servidor adicionado ao catálogo.
2. Gerenciamento de credenciais — cada desenvolvedor precisa de credenciais de nuvem que alcancem os serviços. Em uma empresa, isso significa papéis IAM, limites de permissão e trilhas de auditoria para dezenas de superfícies de ferramentas entre N desenvolvedores.
3. Reproduzibilidade — o comportamento da ferramenta depende da versão instalada de cada servidor e do ambiente local Python/Node. Uma equipe de 10 está executando 10 configurações ligeiramente diferentes.

A solução é hospedar o proxy como um servidor HTTP MCP atrás de um gateway.

Desenvolvedores
    ↕ (HTTP/SSE)
Gateway (autenticação, roteamento)
    ↕ (HTTP interno)
Proxy Hospedado
    ├── cloudwatch-mcp-server (subprocesso)
    ├── cdk-mcp-server (subprocesso)
    ├── ecs-mcp-server (subprocesso)
    └── ... 55 mais

O proxy hospedado é executado uma vez, em um contêiner, com uma identidade de nuvem compartilhada. Os desenvolvedores se conectam via HTTP com autenticação JWT. Eles obtêm o catálogo completo sem nenhuma configuração local. O papel IAM do contêiner do proxy controla o que as ferramentas podem fazer — uma política, auditável, gerenciada centralmente.

O Padrão de Autenticação

O gateway fica entre os desenvolvedores e o proxy hospedado. O padrão de autenticação que torna isso possível em uma empresa sem chaves estáticas:

1. Piscina de Usuários Cognito (ou seu IdP — Okta, Azure AD, mesmo protocolo OIDC) autentica o desenvolvedor
2. Login no navegador PKCE para sessões interativas — sem segredo do cliente, funciona com qualquer provedor OIDC
3. STS AssumeRoleWithWebIdentity troca o IdToken por credenciais temporárias da AWS
4. JWT do Cognito autentica no gateway (CUSTOM_JWT autenticação no gateway valida isso)
5. O papel IAM do proxy hospedado (não as credenciais do desenvolvedor) faz as chamadas reais da API na nuvem

Zero chaves estáticas em qualquer lugar na cadeia. O desenvolvedor prova a identidade via IdP; o papel de serviço do proxy faz o trabalho na nuvem. Gire ou revogue o papel IAM do proxy e todas as sessões conectadas são afetadas imediatamente.

Esse padrão é portátil: troque o Cognito por qualquer provedor OIDC. A etapa de federação STS é padrão. A validação JWT do gateway é padrão. As ferramentas em si são específicas da AWS, mas a arquitetura de autenticação não.

Como é a Experiência do Desenvolvedor

Depois que o gateway é implantado e o desenvolvedor é provisionado i