I repositioned EZLogs around the MCP angle, here is the thinking
Some of you saw the EZLogs post a couple of weeks back, the plain-English activity log for Rails and Next.js. Since then I kept pulling on one thread, and it turned into the sharper version of what this is actually for. Sharing the reasoning in case the repositioning is useful to anyone doing the same.
Short version of what changed: the interesting part is not "readable logs for your team", it is what happens when you let an AI answer questions about your production data, and why that goes wrong by default.
Ask Claude what a specific user did in your app yesterday and it is honest with you: it has no connection to your app, so it cannot say. It will offer to look if you point it at your analytics tool, your database, or a connected integration.
So you point it at your database. That is where it gets interesting. The model now has raw tables, IDs, and join keys it has to decode on its own, and it starts guessing at what they mean. The honest "I cannot" turns into a confident answer that is part real, part invented, and you cannot tell which part is which.
That is the whole problem. Not that the model is dumb. It is being asked a question about your data and handed the wrong shape of data to answer it.
The model never needed your raw schema. It needed the translated layer. That is what EZLogs is now built around. It captures the HTTP requests, background jobs, and database changes behind every user action and folds them into one plain-English activity log: "user 4421 tried to ship their order, the address failed validation, the retry ran three times and gave up." A human on your team can just read that. And it serves the same log to Claude or Cursor over MCP, so an AI can read it too.
The part that matters: the translation has no model in it. It is built from the actual events, deterministically, every line traceable back to the ones that produced it. So when the AI asks, it reads facts instead of inventing them. Same question, same true answer, every time.
I wrote up the full reasoning and the setup (Rails gem, Next.js package, the MCP wiring) here:
https://ezlogs.hashnode.dev/how-to-give-claude-or-cursor-access-to-your-rails-app-s-activity-logs
I posted a version of this to r/rails earlier and got a genuinely good thread back, people using Metabase over MCP, Athena on S3 logs, feeding Claude the schema.rb, the lot. The recurring theme was that connecting an AI to raw data and trusting the answer is the part nobody is fully comfortable with yet. Curious whether that matches your experience too.
This matches my experience exactly. I ship an MCP server for an ad-account monitoring product, and the thing that made it usable was the same call you made: don't hand the model raw API rows, hand it the already-computed answer. My tools return a health score, a named alert, a reconciled number, not the raw tables for the model to interpret. The moment you let it decode join keys on its own, you get a confident answer that's half invented and you can't tell which half. The other piece for me was making every write tool go through an approval step instead of executing. An AI reading facts is one risk. An AI acting on a guess is a much bigger one. Deterministic translation in, guarded actions out. Are you exposing any write tools, or keeping EZLogs read-only for now?
The repositioning logic here is solid — you moved from "what it does" to "why that matters now" and picked an angle (MCP) that has a real tailwind.
We did something similar with Swiftbill. Original positioning: "invoice generator." Nobody searches for that unless they're already bought in. Repositioned around the specific pain: freelancers losing hours a week to invoicing admin, chasing payments, wondering if they got paid. Same product, different frame.
The test I'd apply to any repositioning: can someone who's never heard of you understand in 8 seconds why this exists and why now? The MCP angle passes that test because there's a concrete before/after (Claude can't see your app data → now it can). That's the kind of hook that converts.
The repositioning makes sense but the risk is subtle. "Readable logs for your team" is a solved-category pitch, meaning buyers already know if they want it. Low education cost, but crowded. "Deterministic translation layer for AI agents" is a new-category pitch. Higher upside if MCP becomes standard infrastructure, but you are now selling two things at once: why MCP matters AND why your translation approach is the right one.
The strongest frame in your post is not the MCP angle itself. It is "the model never needed your raw schema, it needed the translated layer." That insight works whether someone uses MCP, Cursor, Copilot, or something that does not exist yet. It is protocol-agnostic, which means it survives the inevitable reshuffling of the AI toolchain over the next 12 months.
If I were testing this repositioning, I would run two versions of the pitch. One leads with MCP (resonates with people already using Claude or Cursor in their workflow). The other leads with "your AI is confidently wrong about your production data, here is why" (resonates with anyone who has seen a hallucinated answer from a DB query). The second audience is much bigger right now, and it does not require the buyer to already care about MCP.
Yep, matches my experience. Point an AI at raw tables and it'll confidently make up half the answer, and you can't tell which half. The deterministic translation layer is a clever angle.
One thing I'd be careful with:
The interesting question may not be whether AI should read translated activity logs instead of raw data.
It may be what users are actually choosing EZLogs for once that layer exists.
Those sound similar, but they can lead to very different positioning decisions.
I wouldn't make that call too quickly from the current signals.