AI has become a normal part of how we write software, reading code and suggesting fixes faster than most traditional resources. However, there's something it still can't do on its own: look at your actual data. This turns out to be a bigger problem than it sounds, effectively leaving your AI assistant blind to the runtime reality of your application.
Consider the workflow when you get a Sentry alert: you paste the stack trace into Claude, providing the error, params, and line numbers. The AI takes a guess at what went wrong, but it remains just that—a guess. It doesn't know what the user record looked like or the state of associated objects. To fix this, you become its hands—running queries and pasting results back and forth. While functional, the AI is only doing half the job it could be doing.
With an MCP (Model Context Protocol) server wired into your Rails app, the AI can investigate on its own. It describes your models, pulls the relevant records, and returns with concrete insights: "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 more back-and-forth; the AI moves from guessing to knowing by accessing the ground truth of your database.
This connectivity also empowers the AI to act as a junior analyst. When product stakeholders ask about feature usage, instead of manually writing SQL queries or building custom dashboards, you can simply ask the AI. "How many users have used the new export feature in the last 30 days? Break it down by plan." The AI calls the right tools, counts, groups, and answers in seconds. It represents the transition from an AI that knows your codebase to one that actually understands what's running in production.
A critical question is security: why not just hand the AI a database URL? Raw SQL access is risky, allowing unintended joins or queries against primary databases without an audit trail. The activerecord-mcp gem addresses this by providing access through the application layer. Queries are validated against actual column names, and sensitive fields like password_digest or secrets are blocked by regex deny lists. By running against a read-only role and using OAuth 2.1 tokens, you apply the same rigorous access control to your AI tooling as you would to any internal API.
