AI has become a normal part of how we write software. It reads code, suggests fixes, and explains things faster than most Stack Overflow answers. But there's something it still can't do on its own: look at your actual data.
That turns out to be a bigger problem than it sounds.
The bug assistant that can actually investigate
You get a Sentry alert. You paste the stack trace into Claude. The error, the params, the line numbers. It reads everything and takes a guess at what went wrong.
The problem is it's just that. A guess. It doesn't know what the user record looked like. It doesn't know what state the associated objects were in. It doesn't know if this is a one-off or whether a whole segment of users ends up here consistently.
So you become its hands. Run the queries, paste the results back, run a few more. It's not the worst workflow, but the AI is doing half the job it could be doing.
With an MCP server wired into your Rails app, it can investigate on its own. It describes your models, pulls the relevant records, and comes back with something like: "Users hitting this error all have onboarding_completed_at null but subscription_active true. Looks like they're skipping a step in the flow." No back and forth. No copy-pasting query results.
Your AI-powered junior analyst
Same problem, different context: you shipped a feature three months ago and someone from product wants to know if it's actually being used.
Normally that means writing a query, building a small report, or filing a ticket with whoever owns analytics. None of that is hard, but there's enough friction that the question quietly dies more often than it gets answered.
With your data accessible via MCP, you just ask. "How many users have used the new export feature in the last 30 days? Break it down by plan." It calls the right tools, counts, groups, and answers in seconds. No SQL, no dashboard, no waiting.
It's the difference between an AI that knows your codebase and one that actually understands what's running in production.
Why not just hand it the database URL?
Fair question. The short answer is that raw database access means raw SQL, and raw SQL means anything goes. Joins across tables you didn't intend to expose, queries hitting your primary instead of your replica, no record of what was accessed.
activerecord-mcp gives the AI access through your application layer instead. Queries go through ActiveRecord with hash conditions validated against actual column names. Sensitive columns like password_digest, tokens, and secrets are blocked by regex deny lists before anything hits the database, and stripped from output after just in case. Everything runs against a read-only role by default. OAuth 2.1 tokens scope access so MCP credentials can't bleed into anything else in your stack.
It's the same access control you'd apply to any internal API, applied to your AI tooling.
Getting started
# 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
Restrict it to the models you want to expose, mount it, and connect:
claude mcp add --transport http my-app https://your-app.com/mcp \
--header "Authorization: Bearer $MY_APP_TOKEN"
Full setup at github.com/pauloancheta/activerecord-mcp.
Top comments (0)