Construímos um Único Endpoint MCP para 36 APIs de Negócios - Aqui Está o Que Aprendemos

O Problema: A Expansão de APIs Está Matando a Produtividade dos Operadores

Todo operador de negócios com quem conversamos tinha a mesma reclamação: eles gastam 40% do seu tempo apenas fazendo login em diferentes plataformas para obter números. Stripe para receita. HubSpot para pipeline. Google Analytics para tráfego. QuickBooks para despesas. Slack para atividade da equipe. GitHub para velocidade de engenharia.

Contamos 36 APIs diferentes que um operador típico de SaaS precisa acessar semanalmente. Isso significa 36 mecanismos de autenticação diferentes, 36 formatos de dados diferentes, 36 padrões de paginação diferentes e 36 limites de taxa diferentes.

Quando a Anthropic lançou o Model Context Protocol (MCP), vimos uma oportunidade: e se pudéssemos colapsar todas as 36 APIs em um único endpoint que qualquer agente de IA pudesse consultar?

O Que Construímos

CorpusIQ é um único endpoint MCP que se conecta a 36 APIs de negócios. Em vez de escrever 36 clientes de integração diferentes, seu agente de IA se comunica com um único endpoint usando um único protocolo. O agente pergunta "Qual é o nosso MRR este mês?" e o CorpusIQ cuida do resto — roteando a consulta para o Stripe, normalizando a resposta e retornando dados limpos e estruturados.

Decisões de Arquitetura que Importaram

1. Somente Leitura por Design

Fizemos a escolha deliberada de ser somente leitura. Sem mutações, sem webhooks, sem operações de escrita. Isso não foi uma limitação — foi uma decisão estratégica. Os operadores precisam de respostas, não de outra ferramenta que possa acidentalmente alterar dados de produção. Somente leitura significa zero risco de um agente alucinar um DELETE na sua conta do Stripe.

2. Fluxo de Dispositivo OAuth

Cada API à qual nos conectamos requer autenticação, e não queríamos estar no negócio de armazenar credenciais. Implementamos o OAuth 2.0 Device Authorization Grant — o mesmo fluxo usado pela Apple TV e dispositivos de streaming. Os usuários autorizam uma vez através de seu navegador, e obtemos tokens revogáveis e com escopo. Sem senhas armazenadas. Sem chaves de API compartilhadas.

3. Arquitetura de Endpoint Único

Em vez de expor 36 ferramentas MCP diferentes (uma por API), expomos uma única ferramenta query com um esquema unificado. O agente não precisa saber qual API chamar — ele apenas faz uma pergunta de negócios. Nossa camada de normalização cuida do roteamento, construção de consultas e formatação de respostas.

4. Consultas de Múltiplas Fontes

É aqui que as coisas ficam interessantes. "Compare nosso gasto em Google Ads com a receita do Stripe por semana" requer acessar duas APIs completamente diferentes com formatos de data diferentes, semânticas de agregação diferentes e modos de erro diferentes. Nosso planejador de consultas decompõe consultas de múltiplas fontes em subconsultas paralelas, depois mescla e normaliza os resultados.

O Que Aprendemos Sobre Normalização de APIs

Normalizar 36 APIs é humilhante. Aqui está o que nos quebrou:

• Formatos de data são um pesadelo. ISO 8601, timestamps Unix, "Q1 2026", calendários fiscais. Construímos um parser de data universal que lida com 14 formatos de entrada diferentes.
• A normalização de moeda requer contexto. O Stripe retorna USD em centavos. O QuickBooks retorna em dólares com 2 casas decimais. O Google Ads retorna micros (milionésimos de dólar). Errar isso significa erros de ordens de magnitude.
• A paginação é inconsistente. Algumas APIs usam paginação baseada em cursor. Outras usam offset/limite. Algumas usam números de página. Uma API que não vamos nomear retorna tudo em uma única resposta, a menos que você passe um cabeçalho específico — e então ela paginates.
• Respostas de erro contam histórias diferentes. Um 429 do Stripe significa "desacelere por 2 segundos." Um 429 do HubSpot significa "você atingiu seu limite diário." O mesmo código de status, remediações completamente diferentes.

Por Que o MCP Foi o Protocolo Certo

Evaluamos REST, GraphQL e gRPC antes de decidir pelo MCP. Aqui está o motivo pelo qual o MCP venceu:

1. A semântica da ferramenta corresponde às consultas dos operadores. O conceito de ferramenta do MCP se mapeia claramente para "me dê dados do Stripe" ou "mostre-me o pipeline do HubSpot."
2. Streaming por padrão. Os operadores querem respostas rápidas. As respostas em streaming do MCP significam que resultados parciais aparecem à medida que chegam.
3. Garantias de saída estruturada. Ao contrário do REST, onde você analisa o que o servidor envia, as ferramentas do MCP retornam respostas tipadas e validadas.
4. Flexibilidade de transporte. O MCP funciona sobre stdio ou HTTP. Escolhemos HTTP para implantação em nuvem, mas a opção stdio significa que os operadores podem executar o CorpusIQ localmente.

O Que Vem a Seguir

• Camada de consulta em linguagem natural: "Como foi o desempenho da nossa campanha de Black Friday?" → decomposição automática entre Google Ads, Stripe e Shopify.
• Relatórios programados: Resumos diários/semanal de todas as fontes conectadas, entregues no Slack ou por e-mail.
• SDK de conector personalizado: Os operadores podem construir seus próprios conectores para APIs internas usando nossa estrutura de normalização.

A Conclusão

O problema da expansão de APIs não vai embora — está piorando. Cada ferramenta de SaaS adiciona outra API à pilha. O MCP nos dá uma maneira de apresentar uma interface unificada para agentes de IA, e a arquitetura de somente leitura, fluxo de dispositivo e endpoint único que escolhemos se manteve bem em 36 APIs muito diferentes.

Se você está construindo algo semelhante, nosso maior conselho: invista em sua camada de normalização desde o início. As decisões sobre o protocolo importam menos do que você pensa. As decisões sobre a normalização de dados importam mais do que você pensa.

CorpusIQ — Um endpoint MCP para 36 APIs de negócios. Conecte suas ferramentas uma vez, faça perguntas em inglês simples, obtenha respostas de todos os lugares.