Boas práticas de MCP de banco de dados

Servidores MCP personalizados permitem que o assistente chame ferramentas dos seus sistemas — inclusive bancos de dados (por exemplo Supabase, Postgres ou um MCP SQL na frente do seu warehouse). Bem feito, o visitante pergunta “cadê meu pedido?” e recebe a resposta real. Mal feito, o chat público pode expor dados de outros clientes. Este guia mostra como conectar um MCP de banco com segurança no Concierge.

O que é (e o que não é)

• É: um servidor MCP remoto (HTTPS Streamable HTTP) em Integrações → Servidores MCP personalizados, com ferramentas aprovadas por workspace.
• É: acesso opcional em chats públicos para o widget (ou canais de mensagem escolhidos) usar só as ferramentas que você marcar.
• Não é: os módulos privados de banco do Concierge nem uma ferramenta custom em código — este caminho é o conector MCP genérico.
• Não é: segurança automática. Ferramentas SQL leem o que as credenciais do servidor permitem; a política fica na escolha de ferramentas, na aprovação e nas Diretrizes.

Arquitetura recomendada

1. Um banco operacional (ou réplica) com pedidos, agendamentos, tickets — a fonte da verdade que o suporte deve consultar.
2. Chaves de busca que o cliente já conhece: número do pedido, código de OS, rastreio, ticket — não “buscar todos os clientes pelo primeiro nome”.
3. Views de suporte (status do pedido com último envio, OS com só o primeiro nome do técnico) para o modelo não montar JOIN complexo a cada turno.
4. Comentários de coluna ou uma nota de schema nas Diretrizes para o agente saber onde olhar.
5. Campos sensíveis fora da resposta: notas internas, documento completo, telefone pessoal de técnico, linhas de outros clientes.

Conectar o servidor

1. 1
   Abrir Integrações

   Vá em Integrações → Servidores MCP personalizados → Adicionar servidor MCP. No Concierge hospedado, use só HTTPS Streamable HTTP.

2. 2
   Autenticar

   Token Bearer, headers customizados ou OAuth conforme o provedor. Segredos ficam criptografados; deixe o campo em branco ao editar para manter o valor atual.

3. 3
   Acesso de membros

   Somente administradores é o padrão seguro para ferramentas de banco. Amplie a papéis selecionados só se o time de suporte precisar das mesmas ferramentas no assistente do console.

4. 4
   Salvar e conectar

   O Concierge descobre as ferramentas e as deixa em quarentena até você aprovar cada uma. Mudança de schema no refresh pode re-quarentena — reaprove após alterações intencionais.

Aprovar ferramentas com critério

• Aprove primeiro list_tables (ou equivalente) e ferramentas de consulta somente leitura.
• Deixe escrita / migration / admin sem aprovação no chat público. Prefira não aprovar para membros também, salvo se a operação realmente precisar no chat.
• Depois de Salvar, ligue Chats públicos só quando estiver pronto: escolha canais (comece pelo widget do site) e marque Chat público em cada ferramenta aprovada que o visitante pode usar.
• Chat público não herda a política de membros — é opt-in por ferramenta e por canal.

Diretrizes que tornam SQL livre “seguro o bastante”

As Diretrizes de visitante (página Diretrizes) valem para canais públicos e o Chat de teste. Elas não mudam como o assistente do console fala com o time. Escreva regras permanentes como:

• Use MCP só para consultas operacionais (pedido, rastreio, OS de instalação, estoque, RMA, ticket, pagamento). Prefira views de suporte quando existirem.
• Antes de endereço, telefone, valor pago ou outros dados privados: exija order_number (ou os_number) E e-mail ou telefone do cadastro.
• Contato errado: recuse sem revelar o titular real.
• Depois de uma falha, se o visitante corrigir com pedido + e-mail/telefone válidos: rode de novo o SQL — não pare em “não está na base de conhecimento” nem só no handoff.
• Nunca SELECT * em customers sem filtro apertado; nunca cite notes_internal; nunca liste pedidos de terceiros.
• Perguntas de catálogo/estoque (disponibilidade por SKU/loja) podem responder sem identidade quando os dados não forem pessoais.

Visitante vs assistente do console

• Visitante (widget / mensageria com ferramentas públicas): portão de identidade + ferramentas estreitas. Espere recusa em dumps e dados de terceiros.
• Assistente do console (barra superior “Trabalhe com seu assistente”): as Diretrizes de visitante não se aplicam. Admins com acesso de membro ao MCP podem rodar SQL mais amplo para operação — trate como privilégio de operador, não como política do suporte público.
• O Chat de teste embute o widget real de visitante. Use “Começar nova conversa” entre personas para ensaiar visitante frio, não uma identidade de teste colada.

Ensaiar antes de ir ao ar

• Caminho feliz: número do pedido + e-mail correto → status e rastreio (ou OS) batem com o banco.
• Caminho parcial: “cadê meu pedido?” sem id → o agente pede número (e contato).
• Adversário: só o pedido → endereço/telefone recusados até validar contato.
• E-mail errado para pedido real → nega sem vazar o dono.
• E-mail certo depois do errado → reconsulta funciona (não só handoff).
• Ataque de dump: listar todos os clientes / notes_internal / pedidos alheios → recusa no chat público.
• Pergunta de estoque/catálogo sem identidade → ok se não for pessoal.
• Console admin: confirme que a operação consulta quando o MCP de membros está ligado (postura diferente é esperada).

Checklist de segurança

• Credenciais do banco são somente leitura para qualquer ferramenta exposta a visitantes.
• Chat público ligado só nos canais desejados (muitas vezes o widget primeiro).
• Ferramentas de escrita e migration sem aprovação no chat público.
• Diretrizes cobrem identidade, reconsulta após erro e proibição de dump/terceiros.
• Notas internas e colunas de PII nunca pensadas para resposta ao visitante.
• Alguém pode desligar o servidor MCP ou revogar ferramentas públicas em um lugar se algo der errado.
• Modo privacidade (quando ativo) trata MCP como sink não confiável — planeje o prompt com isso em mente.

Erros comuns

• Aprovar todas as ferramentas “por conveniência”, inclusive apply_migration.
• Ligar chat público sem marcar ferramentas — nada chega ao visitante até Chat público por ferramenta.
• Confiar só no bom senso do modelo, sem Diretrizes.
• Usar a mesma persona no Chat de teste para vários cenários e vazar contexto entre ensaios.
• Esperar que Diretrizes de visitante limitem o copiloto admin do console (não limitam).

Guias relacionados

• Ensaiar no Chat de teste: roteiros antes do tráfego real.
• Admin: coloque seu workspace no ar: conhecimento, persona, canais, go-live.
• Handoff humano: quando uma pessoa precisa continuar após política ou consulta falha.