Juarez Lustosa
Todos os projetos

MCP para IA: da infraestrutura AWS às ferramentas em produção

Construção de um servidor MCP para assistentes de IA de ponta a ponta, da infraestrutura AWS e do deploy ao desenvolvimento de ferramentas e à observabilidade em produção.

Empresa
Decisiv
Papel
Engenheiro de Software Sênior, time de API
Período
2026
Stack
  • Node.js
  • TypeScript
  • Model Context Protocol
  • OAuth 2.0
  • AWS Lambda
  • ECS
  • Terraform
  • Grafana
  • LogScale

O problema

Clientes começaram a perguntar se poderiam apontar um assistente de IA para a plataforma: “quais dos meus caminhões estão parados em oficina há mais de uma semana?” é uma pergunta que um gerente de serviço faz toda manhã, e respondê-la pela API REST exige várias chamadas e algum cruzamento.

O Model Context Protocol (MCP) dá aos assistentes um jeito padrão de chamar ferramentas. A abordagem ingênua é gerar uma ferramenta por endpoint REST. Tentamos isso primeiro. O assistente recebeu centenas de ferramentas, escolheu as erradas, paginou tudo e queimou tokens e cota de API para responder a uma pergunta simples.

O que eu fiz

Construí a integração MCP de ponta a ponta, da infraestrutura AWS e do deploy ao servidor e às ferramentas usadas pelos assistentes de IA. Esse trabalho incluiu o conjunto de ferramentas curadas, a ponte de autenticação com o OAuth 2.0 e o modelo de permissões existentes, o registro de uso e os dashboards, e as definições de infraestrutura. Também escrevi a especificação técnica e a arquitetura-alvo que o time e os stakeholders revisaram.

Como resolvi

Ferramentas curadas em vez de endpoints espelhados. Um número pequeno de ferramentas responde às perguntas que as pessoas realmente fazem: casos parados de um cliente, a visão geral de um caso com notas e itens, o histórico de serviço de um ativo. Cada ferramenta faz várias chamadas ao Gateway em nome do assistente e devolve um resultado compacto e moldado. Uma chamada curada substitui uma dúzia de chamadas cruas e o assistente para de adivinhar.

Mesma identidade, mesmas permissões. O servidor não tem modelo de acesso próprio. O assistente se autentica com o OAuth da plataforma e toda chamada a jusante carrega o token do usuário, então as ferramentas só enxergam o que aquela pessoa veria na aplicação web. As chamadas de ferramenta são marcadas no span do servidor e aparecem no tracing com os mesmos atributos de qualquer outro cliente da API.

Medição desde o primeiro dia. Toda chamada de ferramenta é registrada com o número de requisições ao Gateway que causou, então o custo por chamada e por cliente é uma consulta, não um chute. Dashboards no Grafana e no LogScale mostram custo ao vivo, fan-out por ferramenta e quais parceiros estão usando.

Infraestrutura como código. Papéis IAM, armazenamento e o serviço de contêineres foram definidos em Terraform junto com o resto da plataforma, seguindo as convenções que o time de SRE já usava, para que o serviço pudesse sair de um protótipo em Lambda para a plataforma de contêineres sem reescrita.

O que foi difícil

Decidir o que não expor. Operações de escrita por um assistente são um risco até a história de confirmação pelo usuário estar sólida, então a primeira versão é somente leitura. A segunda dificuldade foi ter uma visão clara do uso real: separar o tráfego do assistente do resto da API nos logs exigiu um atributo de cliente dedicado atravessando toda a pilha.

O resultado

Um servidor MCP funcionando em staging e produção, demonstrado ao vivo para stakeholders com dados reais de cliente: três chamadas curadas respondem à pergunta dos “caminhões parados” que antes levava uma dúzia de requisições cruas. Uso e custo ficam visíveis por parceiro desde a primeira chamada. A especificação virou a base do roadmap de produto da integração com IA.

Onde conferir

O servidor é um produto da Decisiv e o código é privado. A arquitetura e o raciocínio por trás das ferramentas curadas estão descritos aqui; um diagrama será adicionado quando o lançamento público for anunciado.