DEV Community: Johan Eklund

What MCP Is Actually For, Explained With 200 Bottles of Wine

Johan Eklund — Mon, 27 Jul 2026 20:05:13 +0000

Last month a national magazine wrote about people using Claude as a sommelier. The writer had inherited a cupboard of old bottles from a great-aunt, photographed the labels, and asked Claude what she had. It told her the 1982 Meursault was oxidised and past saving, and that the 1972 Bordeaux came from one of the worst vintages of the decade. Both answers were correct. The piece was still, fairly, a bit sniffy about the whole exercise.

My app (https://cellarion.app) got a passing mention in it, in scare quotes, which is how I ended up thinking about why that experiment was doomed from the start.

Claude did nothing wrong there. It gave good general answers. The problem is that "is this specific bottle worth opening" is not a general question, and no amount of world knowledge gets you to it. That gap is the entire reason MCP exists, and wine turns out to be an unusually clear way to see it.

The gap

A language model knows an enormous amount about wine in general. It knows that white Burgundy from the early eighties is a lottery, that 1972 was a washout in Bordeaux, that Nebbiolo needs time. All of that is in the training data, freely available, and genuinely useful.

What it does not know is what is in your cellar.

So the questions you actually have are the ones it cannot answer. Which of my bottles is closest to falling off. What should I open tonight given I'm cooking lamb. Am I drinking faster than I'm buying. Every one of those depends entirely on private state, and the general knowledge is nearly worthless without it.

This is not a wine problem. It's the shape of most useful questions. Your codebase, your tickets, your customers, your homelab, your library. The model knows the domain and knows nothing about your instance of it.

MCP is the boring plumbing that closes that gap. That's it. It is not a way to make the model smarter. It's a way to let it see your stuff.

What I actually built

Cellarion is a wine cellar app. Free, open source, and I built it with friends after another service made it unreasonably hard to get my own data back out.

The MCP server exposes around 60 tools over a remote endpoint, covering the things you'd expect: search the cellar, get a bottle, place it in a rack, mark it consumed, look up a wine in the shared registry, record a tasting note. Reads mostly, writes where they make sense.

The interesting part is not the tool list. It's what happens when a model can chain them.

Four examples, described rather than pasted

"What should I open tonight?"

Sounds trivial. It isn't. Answering it properly means knowing what's currently in the cellar, which of those bottles are inside their drinking window, whether anything is already open and needs finishing, and ideally what I've been drinking lately so it doesn't suggest the same Chianti for the fourth time. That's several tools and a judgement call. The model does the chaining itself; I just ask the question in the way I'd ask a person.

"What goes with lamb?"

The generic answer to this is free everywhere on the internet and completely useless, because it recommends wines I don't own. The useful version matches the dish against what's physically on my racks right now. Same question, entirely different answer, and the difference is access.

"Am I in trouble?"

Buying pace versus drinking pace, bottles clustered at the end of their window, wines I have too many of. This is the one that genuinely changed my behaviour, and it's the one that would be impossible without state. It's also, I suspect, the version of this that matters in every other domain. The model is good at noticing the pattern once it can see the data.

"Here's what we drank last night."

This is the one I didn't expect to work at all. After a party I photograph the empty bottles standing on the kitchen counter and hand the picture over. Claude reads the labels, matches them against what's actually in my cellar, and marks those bottles as consumed. It lists what it's about to do before it writes anything, which given the circumstances is the correct order of events.

Fifteen minutes of admin that I would simply never have done, turned into one message and a photograph taken while clearing up.

It's worth noticing that this is the same input as the magazine experiment. A photograph of some bottles. In that case the model could only offer general commentary, because there was nothing behind the picture. Here the photograph resolves against real inventory and turns into an action. Identical input, completely different value, and the only thing that changed is that it can see my data.

The things I didn't expect

Some of this was surprising enough that it's the real reason I'm writing this up.

Your data quality becomes the model's problem.

I had a resolution function for matching a wine the user names against the shared registry. It worked acceptably for humans, who tolerate a bad first result and try again. It worked badly for a model, which takes the first plausible answer and proceeds confidently.

The specific failure: producers whose name had been typed into the wine name field as well as the producer field. A human skims past the duplication. The matcher scored those entries wrong and the model built on the bad match without hesitating. The bug had been sitting there for months, invisible, because every human user had been silently working around it.

Exposing a database to a model is a data quality audit you didn't ask for.

Writes are a different category from reads.

Reads are forgiving. If the model fetches the wrong bottle, you notice and correct it. Writes are not, especially when they touch data other people see.

Cellarion has drinking windows that are shared across every user. If a wine is marked as peaking between 2028 and 2034, everyone sees that. Letting a model write to shared reference data unsupervised is a bad idea no matter how good it is, so the workflow is that it proposes values and I confirm before anything is written. Never once regretted it.

If you build one of these, split your tools by blast radius rather than by feature area, and put the friction where the damage would be permanent.

More tools is not straightforwardly better.

There's a point where adding tools starts costing you accuracy, because tool selection is itself a hard problem and the model has to pick correctly before it can do anything useful. Clear names help. Descriptions that say when not to use a tool help more than descriptions that say what it does. Annotations marking which tools are read-only and which are destructive help the client behave sensibly.

I don't have a clean number for where the ceiling is. I do know that "expose everything" is not a strategy.

It's a fresh look at your own API.

Every place my tools were confusingly named or badly scoped, the model found it by using them wrong. It can't ask a colleague what the field means. It reads the description and commits. That is a rather unforgiving reviewer and it improved the design.

Where it doesn't help

It doesn't taste anything. It has no idea whether your specific bottle was stored badly, which is exactly why the magazine experiment went the way it did. Photographs of a dead cupboard are the hardest possible input, because there's nothing to check the answer against.

And I'd say this about the tool generally: it's a multiplier on what you bring. I get good code out of Claude because I've written code long enough to see the mistake immediately. I get good wine answers because I know enough to argue back. Ask it about something you can't evaluate and it sounds precisely as confident as it does when it's right. That's the part worth being careful about, and it doesn't go away when you add MCP. It just gets faster.

If you're thinking about building one

Pick the thing where your private state matters more than world knowledge does. That's the whole heuristic. If the general answer is already good enough, MCP adds nothing but latency. If the general answer is useless without knowing your specifics, that's where it earns its place.

For me that turned out to be two hundred bottles in my basement. It'll be something else for you.

The code is open source if you want to see how the server is put together: github.com/jagduvi1/Cellarion

How I Built an 80,000-Line Open Source Wine Cellar App in 6 Weeks with Claude

Johan Eklund — Sun, 05 Apr 2026 14:51:05 +0000

I'm a wine collector. I'm also a developer. And like most developers, when I couldn't find an app that did what I wanted, I built my own.

The result is Cellarion — a full-featured, self-hosted wine cellar management app (https://cellarion.app). Free, open source, and built almost entirely with Claude as my coding partner.

In about 6 weeks, we went from zero to a production app with 80,000+ lines of code, 40 database models, 47 API routes, 290+ commits, and real users. Here's how.

The Problem

I tried a few wine cellar apps. They all had the same issues:

Your data was locked in. Exporting was either impossible or deliberately painful.
Features were paywalled — sometimes basic ones.
They didn't let me visualize my actual cellar layout.
No community-driven wine database. Every user entering the same wines manually.

So I opened a terminal and started building.

The Stack

I went with a classic MERN stack, containerized with Docker Compose:

MongoDB + Mongoose for data
Express.js for the API
React 19 for the frontend
Meilisearch for fuzzy wine search
Docker Compose to tie it all together
rembg (Python/Flask) for automatic wine label background removal

Nothing exotic. Proven tools that work well together and are easy to self-host.

Enter Claude

Here's where it gets interesting. I didn't build this alone. Claude was my development partner from day one — not as a code generator I copy-paste from, but as a genuine collaborator.

What that actually looks like

A typical session: I describe what I want at a high level. Claude reads the existing codebase, understands the patterns, and implements it — backend route, frontend page, database model, tests. Then I review, test, and we iterate.

Some examples from the last few weeks:

"I want users to be able to share their cellar with friends and family"
Claude implemented the full sharing system — invite by email, role-based permissions (viewer/editor/admin), pending share resolution when someone registers, notifications, and the UI for managing it. Across maybe 15 files. In one session.

"The wine detail pages need structured data for Google"
Claude added JSON-LD schema markup, Open Graph meta tags, a server-side pre-rendering route for crawlers, and a sitemap generator. When Google Search Console flagged an issue with Product schema on wines without reviews, Claude diagnosed it and fixed it the same day.

"I want a 3D view of the cellar"
This one was fun. Claude built an interactive 3D cellar visualization where you can explore your racks, see bottles placed in their slots, and navigate around. Using Three.js and React Three Fiber, integrated with the existing rack and bottle data.

What Claude is actually good at

Understanding context. It reads your codebase and follows your patterns. My API routes all follow the same structure, and Claude picks that up immediately.
Full-stack thinking. It doesn't just write a backend endpoint — it writes the model, the route, the API client function, the React page, and the tests. All consistent with the existing code.
The boring stuff. GDPR compliance, data export endpoints, audit logging, rate limiting, input validation. The stuff you know you need but really don't want to write. Claude does it thoroughly.
Iteration speed. I can describe a feature, get a working implementation, test it, and ship it in a single session. That feedback loop is incredible for a solo/small team.

What it's not

Claude isn't magic. I still need to:

Know what I want. Claude is a great builder, but you need to be the architect.
Review everything. It makes mistakes. It sometimes over-engineers. It occasionally misses edge cases that only a domain expert would catch.
Make product decisions. Which features matter? What's the right UX? What should be free vs. paid? That's all human judgment.
Test in production. Docker, real data, real users — no AI replaces that.

Going Open Source

This was a deliberate choice. If your biggest complaint about existing apps is data lock-in, you'd better put your money where your mouth is.

Cellarion is AGPL-3.0. You can:

Self-host it on your own server
Fork it and modify it
Contribute features back
Export all your data whenever you want

The hosted version at cellarion.app is there for people who don't want to run Docker on a VPS, but the code is the same.

What's in the App

After 6 weeks of building, here's what Cellarion can do:

Cellars & Racks — Create cellars with customizable rack layouts that match your real setup. Place bottles in specific slots.
3D Cellar View — Explore your cellar in an interactive 3D environment.
Shared Wine Database — Search a community-maintained database instead of entering wine details manually every time.
Drink Windows — Maturity tracking so you know when a wine is ready to drink, at its peak, or past it.
Statistics — See your collection broken down by region, grape, country, value, and more. Including a world map.
Cellar Sharing — Invite family or friends to view or manage your cellar together.
Label Scanning — Take a photo of a wine label and let AI identify the wine.
Full Data Export — One click and you have all your data. No lock-in, ever.
GDPR Compliant — Proper consent management, data portability, and right to deletion.

The Numbers

Metric	Value
Time to build	~6 weeks
Lines of code	80,000+
Commits	290+
Database models	40
API routes	47
Frontend tests	266
Backend tests	335
License	AGPL-3.0
Price	Free

Try It

Hosted version: cellarion.app
GitHub: github.com/jagduvi1/Cellarion
Self-host: docker-compose up --build and you're running

If you're into wine, give it a try. If you're a developer, check out the code. And if you find something missing, open an issue — or better yet, a PR.

I'd love to hear what you think.