Seu assistente de IA é cego para seus dados. Veja como corrigir isso.

A IA se tornou uma parte normal de como escrevemos software. Ela lê código, sugere correções e explica as coisas mais rápido do que a maioria das respostas do Stack Overflow. Mas há algo que ela ainda não consegue fazer sozinha: olhar para os seus dados reais.

Isso acaba sendo um problema maior do que parece.

O assistente de bugs que pode realmente investigar

Você recebe um alerta do Sentry. Você cola o stack trace no Claude. O erro, os parâmetros, os números das linhas. Ele lê tudo e faz uma suposição sobre o que deu errado.

O problema é que é apenas isso. Uma suposição. Ele não sabe como era o registro do usuário. Ele não sabe em que estado estavam os objetos associados. Ele não sabe se isso é um caso isolado ou se um segmento inteiro de usuários acaba aqui consistentemente.

Então você se torna suas mãos. Executa as consultas, cola os resultados de volta, executa mais algumas. Não é o pior fluxo de trabalho, mas a IA está fazendo metade do trabalho que poderia estar fazendo.

Com um servidor MCP conectado ao seu aplicativo Rails, ele pode investigar por conta própria. Ele descreve seus modelos, puxa os registros relevantes e volta com algo como: "Usuários que estão enfrentando esse erro têm onboarding_completed_at nulo, mas subscription_active verdadeiro. Parece que eles estão pulando uma etapa no fluxo." Sem idas e vindas. Sem copiar e colar resultados de consultas.

Seu analista júnior alimentado por IA

Mesma problema, contexto diferente: você lançou um recurso há três meses e alguém do produto quer saber se ele está realmente sendo usado.

Normalmente isso significa escrever uma consulta, construir um pequeno relatório ou abrir um ticket com quem quer que possua a análise. Nada disso é difícil, mas há fricção suficiente para que a pergunta morra silenciosamente mais vezes do que é respondida.

Com seus dados acessíveis via MCP, você apenas pergunta. "Quantos usuários usaram o novo recurso de exportação nos últimos 30 dias? Quebre por plano." Ele chama as ferramentas certas, conta, agrupa e responde em segundos. Sem SQL, sem painel, sem espera.

É a diferença entre uma IA que conhece seu código e uma que realmente entende o que está rodando em produção.

Por que não apenas entregar a URL do banco de dados?

Pergunta justa. A resposta curta é que o acesso direto ao banco de dados significa SQL bruto, e SQL bruto significa que qualquer coisa pode acontecer. Joins entre tabelas que você não pretendia expor, consultas atingindo seu primário em vez de seu réplica, sem registro do que foi acessado.

activerecord-mcp dá à IA acesso através da camada da sua aplicação. As consultas passam pelo ActiveRecord com condições de hash validadas contra nomes de colunas reais. Colunas sensíveis como password_digest, tokens e segredos são bloqueadas por listas de negação regex antes que qualquer coisa atinja o banco de dados e removidas da saída apenas por precaução. Tudo roda contra um papel somente leitura por padrão. Tokens OAuth 2.1 limitam o acesso para que as credenciais do MCP não vazem para nada mais em sua pilha.

É o mesmo controle de acesso que você aplicaria a qualquer API interna, aplicado às suas ferramentas de IA.

Começando

# Gemfile
gem "activerecord-mcp"
gem "doorkeeper"

bundle install
bin/rails generate doorkeeper:install
bin/rails generate doorkeeper:migration
bin/rails db:migrate
bin/rails generate rails_mcp:install

Restringa aos modelos que você deseja expor, monte-o e conecte:

claude mcp add --transport http my-app https://your-app.com/mcp \
  --header "Authorization: Bearer $MY_APP_TOKEN"

Configuração completa em github.com/pauloancheta/activerecord-mcp.