# The client runs his admin from Claude. A private MCP, wired to production, in three weeks.

> A non-technical client got an MCP instead of more admin screens. He now creates catalogue products by chatting, on a server that reaches production through one authenticated user and logs every call.

- Use case · AI and Automation · Aug 2026 · 4 min read
- Source: https://giovannidimeo.com/blog/private-mcp-server-in-production/
- Author: Giovanni Dimeo, https://giovannidimeo.com/

A client who is not technical had an admin dashboard that kept growing: a menu, a form and a button for everything the platform sells. Instead of more screens, I gave him a private [Model Context Protocol (MCP) server](/#services): he creates the same resources from a Claude conversation. It runs outside the platform, reaches production through the REST API as **one authenticated user**, **drafts before it publishes** and **writes every call to the audit log**. **Three weeks of work, solo.**

## Context

The platform sells products. Each one is several resources: the product, its public page, an SEO page, a price plan, its entry on Stripe and one in the search index. Creating one meant walking the admin in the right order and getting every field right.

The person doing it is the client himself, not an engineer. He knows the products by heart and does not enjoy the admin. Watching him work was the brief: the dashboard was correct and complete, and still the slowest part of every launch.

## The problem

- Every new product was a sequence of screens, easy to get wrong.
- The knowledge lived in his documents and his head, not in a form.
- More admin features meant more menus, more buttons, more training.

## What we decided

My proposal: keep the dashboard as the place to check, and add a second way in for the person who creates. That way is a Model Context Protocol server, private to this client, that Claude can call. Four decisions shaped it.

- The MCP runs in its own cloud and reaches production only through the same REST API everything else uses. **Nothing new touches the database.**
- One user, chosen on purpose. He signs in with Google (OAuth); **the MCP server acts with his token and nothing more.**
- **Every tool call is written to the audit log**: who, what, result.
- **Nothing goes live from a chat.** The tools create drafts; he checks them in the dashboard and publishes there.

> The dashboard stayed the source of truth. The MCP became the fast way to fill it.

## What was built

Nine tools, one per thing the admin can do: create and update a product, upsert its page and its SEO page, attach a plan, sync it with Stripe, publish, reindex search, list categories. Each tool validates its input like the admin forms, so **a bad price or a missing category fails before it reaches production**.

The MCP holds the selected user’s Google token and forwards it on every request: authorization is what that user may do in production, no wider. **A call from anyone else is refused at the door.** Create and update produce drafts, logged as their own events; publishing is a separate tool and, for now, a decision taken in the dashboard.

## What changed

The client creates resources from his own documents by chatting: he pastes a product description, Claude calls the tools in order, a draft appears in the dashboard. He has asked for more resources to be reachable this way, which is the outcome I care about: **the admin stopped being the bottleneck.**

The MCP stays internal, built for one client, not public.

## What I would do again

Put the MCP server outside the platform, behind the existing API: the security review is then about one user and one token, not a new system. Log everything and publish nothing from the chat. And start from the person’s documents, not the admin’s menus: the tools mirror what he wants to say, not what the forms want to hear. The same tools layer, with a human in the loop, is what a [customer support chatbot](/blog/ai-customer-support-chatbot-human-in-the-loop/) needs to answer with facts instead of scripts.

## Takeaways

**What was decided.**

- Keep the dashboard as the place to check. Add an MCP as the fast way to create.
- One chosen user, Google sign-in, his token and nothing more.
- Drafts from the chat. Publishing stays a human decision in the admin.

**How it stays safe.**

- The MCP runs in its own cloud and reaches production only through the REST API.
- Every tool call is written to the audit log: who, what, result.
- Nine tools that validate like the admin forms. Bad input fails before production.

## Questions people ask

**Is it safe to connect an MCP server to production?**

It can be, when the server runs outside the platform, reaches production only through the existing API as one authenticated user, creates drafts instead of publishing, and writes every call to the audit log. That is the setup in this piece.

**Who can call the tools?**

One user, chosen on purpose, signed in with Google. The MCP server acts with his token, so it can do exactly what he can do in the admin and nothing more. Anyone else is refused.

**What happens if the model sends a wrong value?**

Each tool validates its input the way the admin forms do, so a bad price or a missing category fails before it reaches production. What passes becomes a draft the person checks in the dashboard.