MCP em dados brutos pode recriar o inferno do Excel, agora na velocidade das máquinas

O texto da dltHub parte de um cenário simples: um agente de IA ligado por MCP direto ao Salesforce, Stripe e HubSpot. O CFO pergunta a receita do trimestre e ouve US$ 1,2 milhão. Vendas faz a mesma pergunta ao mesmo agente e recebe US$ 1,4 milhão. Ninguém sabe qual número vale. É o mesmo problema das planilhas de Excel de cada departamento, de antes dos data warehouses.

O argumento técnico é que o analista sempre trouxe a semântica (o que é "cliente ativo", qual tabela confiar, quais linhas descartar) e o warehouse trouxe a precisão, com regras de negócio em código. O agente assume o papel do analista, mas não substitui o warehouse. A proposta são duas camadas: uma de significado (ontology, o dicionário de negócio que diz o que é cliente, qual receita conta e onde cada dado mora) e uma de precisão (regras como código testado, valendo para todas as fontes). Os agentes continuam usando MCP, mas por ferramentas mapeadas à camada de significado, não direto nos sistemas brutos. O texto lembra ainda que MCP bruto muitas vezes vem com acesso de escrita, então um palpite errado pode alterar dado, não só um relatório. A versão mais simples é colocar um MCP sobre o warehouse existente e acrescentar a ontology nele. Databricks (Unity Catalog Business Semantics e Genie Ontology) e Snowflake (Semantic Views e servidores MCP governados) já oferecem a camada de significado. A dltHub posiciona sua ferramenta como a que constrói pipeline, modelo, ontology e metric view alinhados às definições de negócio.

Para quem opera dados, a leitura é prática: antes de liberar um agente em produção, pergunte se duas áreas obterão o mesmo número para a mesma métrica. Se a resposta for "provavelmente", a governança ainda não está pronta. O custo de definir regras uma vez, em build time, tende a ser menor que o de reconciliar métricas conflitantes depois. Vale lembrar que o texto vem de um fornecedor, que vende justamente essa solução.