Como o Pinterest construiu um ecossistema MCP de produção para agentes de IA

• Experiência do Pinterest ao adotar o MCP como padrão de conexão de ferramentas para agentes de IA e integrá-lo em nível de produção a fluxos reais de engenharia, como IDEs, chat interno e agentes de IA
• Escolha de uma arquitetura que combina vários servidores MCP por domínio (Presto, Spark, Airflow etc.) com um registro central, em vez de um único servidor monolítico
• Aplicação do princípio de menor privilégio sobre dados sensíveis com uma camada dupla de autenticação composta por JWT do usuário final + identidade de malha SPIFFE e controle de acesso baseado em grupos de negócio
• Alcance de resultados quantitativos de 66.000 chamadas por mês, 844 usuários ativos mensais e uma economia estimada de 7.000 horas por mês
• O que consolidou o MCP não como um experimento simples, mas como infraestrutura de produtividade de engenharia foi um design com segurança em primeiro lugar, um pipeline de implantação unificado e integração direta às ferramentas que os funcionários já usam

---

Contexto da adoção do MCP

• O Model Context Protocol (MCP) é um padrão open source que usa um protocolo unificado cliente-servidor quando LLMs se comunicam com ferramentas e fontes de dados, em vez de implementar integrações separadas para cada modelo e ferramenta
• O Pinterest usou o MCP não para simples Q&A, mas como base para automação de tarefas de engenharia — com objetivos que vão de “leia os logs e encontre o problema” até “analise um ticket de bug e proponha um PR de correção”

Projeto da arquitetura inicial

Hospedagem em nuvem, não local

• Embora também ofereça suporte ao modo de servidor MCP local (comunicação via stdio), o Pinterest adotou como caminho padrão (paved path) os servidores MCP hospedados na nuvem interna
  • O objetivo era operar em um ambiente no qual fosse fácil aplicar lógica interna de roteamento e segurança
  • Servidores locais são permitidos apenas para experimentação

Vários servidores pequenos vs. um único servidor monolítico

• Em vez de um único servidor gigante, foram escolhidos vários pequenos servidores MCP por domínio
  • É possível aplicar controles de acesso diferentes por servidor
  • Evita que o contexto do modelo seja preenchido desnecessariamente
• Feedback inicial: houve a crítica de que criar um novo servidor MCP exigia trabalho prévio demais, como pipeline de implantação, configuração de serviço e setup operacional
  • Como solução, foi criado um pipeline de implantação unificado — as equipes só precisam definir a lógica das ferramentas, e a plataforma cuida automaticamente da implantação e da escalabilidade

Registro interno de MCP

• Uma fonte única da verdade (source of truth) que gerencia a lista de servidores MCP aprovados e a forma de conexão
• Web UI: permite que pessoas explorem servidores, equipe responsável, canal de suporte, postura de segurança, status ao vivo e ferramentas disponíveis
• API: usada por clientes de IA (chat interno de IA, integração com IDE, agentes) para descobrir e validar servidores e determinar “este usuário pode usar o servidor X?”
• Apenas os servidores registrados no registro são reconhecidos como servidores aprovados para produção — funcionando como espinha dorsal de governança

Situação atual dos servidores MCP em operação

Servidores principais (por uso)

• Servidor MCP do Presto: o servidor mais usado em termos de tráfego — agentes (incluindo IDEs com suporte de IA) consultam dados baseados em Presto sob demanda e usam os dados diretamente no fluxo de trabalho, sem trocar para um dashboard
• Servidor MCP do Spark: base da experiência de depuração de Spark com IA — oferece suporte a diagnóstico de falhas de jobs Spark, resumo de logs e registro estruturado de análise de causa raiz, transformando threads operacionais em conhecimento reutilizável
• Servidor MCP de Knowledge: endpoint de conhecimento de uso geral — usado pelo bot interno de IA para conhecimento corporativo, Q&A, documentação e perguntas de depuração

Integração com serviços internos do Pinterest

• Ferramentas MCP integradas à interface web interna de chat com LLM, usada diariamente por muitos funcionários do Pinterest
  • O frontend executa automaticamente o fluxo OAuth e depois retorna a lista de ferramentas permitidas ao usuário atual
  • O agente de chat com IA vincula diretamente as ferramentas MCP ao conjunto de ferramentas do agente, oferecendo a mesma experiência de uma chamada de ferramenta comum
• Ferramentas MCP também incorporadas ao bot de IA da plataforma interna de chat
  • Autenticação e autorização tratadas via API do registro
  • Suporte a restringir ferramentas MCP específicas a canais específicos (por exemplo, ferramentas MCP do Spark só podem ser usadas no canal de suporte do Airflow)

Segurança, governança e políticas

Padrão de segurança do MCP

• Foi definido separadamente um MCP Security Standard — todos os servidores MCP que não sejam experimentais devem obrigatoriamente ter equipe proprietária designada, registro no registro interno e aprovação de tickets de revisão de segurança/jurídico-privacidade/(quando aplicável) GenAI
• Com base no resultado da revisão, são definidas políticas de segurança, como os grupos de usuários que podem acessar o servidor

Camada dupla de autenticação (AuthN) e autorização (AuthZ)

• Fluxo baseado em JWT do usuário final

  1. O usuário interage em uma surface como chat com IA, plugin de IDE ou bot de IA
  2. O cliente executa o fluxo OAuth sobre a stack interna de autenticação e passa o JWT para o registro MCP e para o servidor de destino
  3. O Envoy valida o JWT, faz o mapeamento dos headers X-Forwarded-User e X-Forwarded-Groups e aplica políticas de segurança em nível mais amplo
  4. Dentro do servidor, o decorador @authorize_tool(policy='…') faz o controle fino de permissões (por exemplo, get_revenue_metrics só pode ser chamado pelo grupo Ads-eng)

• Controle de acesso baseado em grupos de negócio

  • Em vez de conceder acesso em bloco a todos os funcionários e contratados autenticados do Pinterest, servidores sensíveis extraem do JWT a associação a grupos de negócio e verificam se o usuário pertence a um grupo aprovado
  • O servidor MCP do Presto pode ser tecnicamente acessível a partir de várias surfaces, mas apenas grupos aprovados, como Ads, Finance e certas equipes de infraestrutura, podem estabelecer sessão e executar ferramentas de alto privilégio

• Fluxo baseado em SPIFFE para serviços

  • Em cenários de baixo risco e somente leitura, o tratamento é feito apenas com autenticação baseada em SPIFFE (identidade de malha)
  • Esse modelo é usado apenas quando não há usuário final no loop e o raio de impacto é rigidamente limitado

Diferença em relação ao padrão OAuth do MCP

• A especificação oficial do MCP define um fluxo de autenticação OAuth 2.0 por servidor (tela de consentimento, gestão de tokens por servidor), mas o Pinterest adotou uma abordagem de reaproveitamento da sessão existente
  • Quando o usuário abre uma surface como o chat com IA, ele já está autenticado na stack interna de autenticação — não são necessários prompts adicionais de login nem diálogos de consentimento
  • O Envoy e os decoradores de política tratam a autorização em segundo plano, de forma transparente

Human-in-the-Loop

• Como os servidores MCP viabilizam ações automatizadas, o raio de impacto é maior do que em operações manuais
• Seguindo a orientação do agente, aprovação humana é obrigatória antes de ações sensíveis ou custosas — o agente propõe a ação, e a pessoa aprova ou rejeita (inclusive em lote)
• Uso de elicitation para solicitar confirmação antes de ações arriscadas (por exemplo, sobrescrever dados de uma tabela)

Observabilidade e métricas de resultado

• Funções de biblioteca aplicadas a todos os servidores MCP — logging de entrada e saída, contagem de chamadas, rastreamento de exceções e telemetria fornecidos por padrão
• Métricas medidas no nível do ecossistema: número de servidores e ferramentas MCP registrados, total de chamadas aos servidores e tempo estimado economizado por chamada (calculado pelos donos dos servidores com base em feedback leve de usuários e comparação com fluxos manuais anteriores)
• Uma única métrica norteadora: tempo economizado (time saved) — cálculo aproximado do impacto como número de chamadas × minutos economizados por chamada
• 66.000 chamadas por mês, 844 usuários ativos mensais e uma economia estimada de 7.000 horas por mês