Como um servidor MCP de dados de marketing deve ser desenhado: escopo, leitura e custo

Ligar uma IA aos dados de vendas e anúncios é uma URL e uma autorização. Fazer isso sem que a IA leia o cliente errado, apague um conjunto de dados ou varra um bilhão de linhas é desenho — e a maioria dos defeitos que achamos, inclusive nos nossos, tem a mesma forma: a regra estava escrita e ninguém a aplicava.

O MCP tirou o atrito de conectar uma IA a um sistema. Isso é bom e é o problema: quando ligar é fácil, o servidor é construído às pressas e nasce com acesso total, porque é o jeito mais simples de fazer funcionar. Depois vêm os clientes, e o acesso total vira o risco de um cliente ler o outro.

Este artigo é a lista do que um servidor MCP de dados de marketing precisa ter para servir várias empresas na mesma instalação. Cada item nasceu de um defeito real — a maioria achado em auditoria da nossa própria implementação, e todos com a mesma assinatura: nenhum teste quebrou, porque uma peça que não é chamada não quebra nada.

1. O projeto ativo não mora no token

A tentação é gravar "este token vale para o projeto X" na hora de autorizar e confiar nisso até o token expirar. O defeito: se alguém é removido da equipe, o token dele continua válido — e a renovação copia o projeto adiante sem reconferir. Medimos uma janela de 90 dias de acesso depois da remoção. A regra: toda chamada que toca dado passa por um funil único que confere a participação AGORA, com cache curto, e falha FECHADO — erro ao consultar a permissão não pode virar passe livre.

2. Só leitura é aplicado, não declarado

O MCP permite anotar uma ferramenta como "somente leitura". A anotação é documentação: não impede nada. O servidor tem de derivar o escopo exigido da anotação e recusar a chamada na hora, para toda ferramenta — inclusive as antigas, registradas por outro caminho. Achamos um conjunto de ferramentas legadas onde o token de leitura conseguia apagar um conjunto de dados, porque o registro delas pulava a checagem que as novas tinham.

Ler a autorização e jogá-la fora é pior do que não ler: parece que foi considerada.

3. A consulta roda isolada

Se a IA pode escrever SQL — e ela deve poder, é o que a torna útil —, o servidor precisa de um sandbox que recuse: schema de outro cliente citado pelo nome, tabela global do banco, função que lê arquivo ou rede, e qualquer comando que não seja SELECT. E a recusa tem de ser no servidor, com a árvore da consulta, não no prompt. Prompt é sugestão; parser é regra.

4. O segredo nunca atravessa o modelo

Conectar uma fonte exige senha do banco do cliente, token da plataforma de anúncios, chave de API. Nenhum deles deve passar pela conversa com a IA — o modelo registra tudo o que vê. O padrão que adotamos: a ferramenta cria o recurso SEM o segredo e devolve um link autenticado onde a pessoa cola a credencial na tela do produto. A IA pede; o app completa. É o mesmo princípio de IA e dado confidencial, aplicado ao próprio ato de conectar.

5. Toda pergunta tem custo, e o custo tem teto

Uma IA curiosa varre tabelas. Medimos: o conector de IA de um projeto leu 143 GB num mês, 16 vezes mais execuções do que a interface. Não é defeito da IA; é ausência de régua. O servidor precisa medir bytes lidos por chamada, atribuir ao projeto e ao ator, ter limite de simultaneidade por plano, e devolver o custo na resposta — para a pessoa saber o que a pergunta custou. Escrevemos sobre isso em quanto custa uma pergunta aos dados.

6. Dado de pessoa é escopo, não papel

Um analista pode rodar SQL e não pode ver e-mail e telefone. Isso não é um papel a mais; é uma dimensão separada. O jeito seguro de aplicar é por VISÃO que já nasce sem os campos de contato — não por apagar coluna, porque contato vaza dentro de JSON. E a lista do que é contato vem por PADRÃO DE NOME, não por lista fixa: uma lista fixa não conhecia o campo de CPF de uma tabela nova e o entregava ao escopo "sem dado pessoal".

7. O que a ferramenta promete tem de existir

O defeito mais silencioso de todos: ferramentas registradas numa lista que ninguém servia. Onze ferramentas de audiência ficaram meses fora do conector porque a rota HTTP montava a lista à mão e a lista do código era outra. Os testes passavam — exercitavam a lista morta. A regra: uma lista só, o servido deriva dela, e um teste que varre o disco atrás de todo grupo de ferramentas e quebra quando um não está plugado.

No CrazyLeads cada um desses sete itens é código e tem uma guarda que o prova — porque cada um foi, em algum momento, um defeito.