Stop Guessing Your Rails Stack: What Your Coding Agent Can Do With BuiltOnRails MCP

Ask your AI coding agent what background job system to use for a new Rails app and it answers confidently, from blog posts written in 2022, from "what I use" threads, and from training data that predates Solid Queue shipping as a Rails default. It does not answer from what production apps run today, because there was nowhere for it to look.

Now there is. BuiltOnRails runs an MCP server over the real Gemfiles of 148 production Rails apps, 823 recorded stack choices across 113 technologies. Connect it once and your agent reasons from evidence instead of averaged internet folklore.

The problem is not that agents are wrong

They are doing their job. A model tells you what the internet said, weighted by how often it said it. That is a reasonable way to answer a question about opinion and a poor way to answer a question about what production systems actually run.

Ask "is Solid Queue production ready?" and you get a debate. Ask "what database do Rails SaaS apps use?" and you get "probably PostgreSQL?" with no number attached. The information exists. It is sitting in dependency files, one codebase at a time, where nothing can read it.

What the Gemfiles say today

Question	Answer from real apps
Most used database	PostgreSQL, 77 apps
Background jobs	Sidekiq 41, Solid Queue 11
Apps analysed	148
Stack choices recorded	823
Technologies tracked	113

Sidekiq 41 against Solid Queue 11 is not an argument that either is better. It is an observation that Rails 8 made Solid Queue the default over a year ago and the framework default has not become the production default yet. Anyone telling you everyone has moved, or that nobody has, is guessing.

These numbers move as listings come in, which is exactly why they are worth querying rather than memorising.

Connect it in one line

claude mcp add builtonrails --transport sse https://builtonrails.com/mcp/sse

No API key. The data is public and reads are open on purpose. Cursor, Claude Desktop, Windsurf and any MCP compatible client work the same way. Setup for each is at builtonrails.com/agents.

What your agent can do with it

Twelve public tools. The four that change how you start a project:

• compare_stacks gives head to head adoption with the counts attached, so you can see the sample size rather than trusting a score.
• detect_stacks takes a pasted Gemfile and returns the adoption landscape for everything in it.
• get_products_using_stacks answers "show me apps running PostgreSQL and Hotwire and Solid Queue" with the actual apps and their full stacks.
• get_stack_recommendations uses co-occurrence: given what you already run, what do similar production apps reach for next.

What it cannot tell you yet

Being straight about this, because you will find it anyway.

Of the 113 technologies tracked, 38 appear in five or more apps. Five is enough to see a pattern, not enough to call it representative, so treat those as a starting point rather than a verdict. The rest are too thin to compare at all. Every tool returns the counts alongside the answer so you can judge that yourself instead of taking a number on faith.

The dataset is Gemfiles from apps listed here. It is not a census of every Rails app in the world and does not pretend to be. The server is live and works. It has no adoption yet. You would be early.

When you would actually reach for it

Most Rails developers do not open an MCP client every morning to research stacks. Day to day you build with what your team already knows, and deliberate stack research is rare.

The value shows up when the agent is already in the loop. If Claude Code or Cursor is scaffolding your project anyway, the difference between it answering from training data and answering from live production evidence is one connection. That matters when you are starting something new, when you are revisiting an old decision, and when you are teaching someone and would rather point at a number than at your own preference.

If you ship Rails, this is the selfish part

Here is the honest version of the ask.

The apps in this dataset are what a developer's AI reads when it is asked what to build with. Almost nobody is asking it yet. If that changes, being in it is distribution. If it does not, you spent a minute. That is a more honest reason to bother than a badge is, and you can see the odds.

Add your app and you are done. No description to write, no form to fill in.

Do not send me your Gemfile. I asked for that in an earlier version of this post and it was a bad idea: a Gemfile can carry private gem server URLs with credentials in them. If the repository is public, point me at it. If it is not, name the gems you would list if a new hire asked what you run. What gets published is the technology names and nothing else.

Every real stack added makes the next answer sharper, including the answers you get back.

Stop guessing your Rails stack. Ask something that has read the Gemfiles.