How I Built an Open-Source MCP Server for E-Commerce (And What I Learned)

I've always had this gut feeling that AI-to-AI communication would eventually become the norm — machines talking to machines on behalf of humans. But for the longest time, I had no idea how to actually get there.

From vibe coding to a real product problem

I'm a solo fullstack developer who builds with AI. Not just uses AI — builds with it. Vibe coding is incredible: you can prototype, ship, and iterate faster than ever before. With a product background and neural networks as my co-pilot, I've been shipping projects solo that would have required a team just two years ago.

At some point, I had an idea: what if I could build a SaaS that generates an AI chat widget for any small or mid-sized business in about 10 minutes, just by feeding it the website's content? So I built it. And then I realized — there are dozens of tools like this. The difference isn't the widget. The difference is specificity.

The moment everything clicked

My first real client was a store I had previously built a Next.js e-commerce site for — a company that sells sports nets. They had a large product catalog with detailed specs, variations, and niche terminology.

Here's what I discovered: when you dump an entire product catalog into an LLM's context, it gets lost. The responses become vague, hallucinated, or just wrong. A customer asks "which net fits a 3x4 meter frame?" and the AI confidently recommends something that doesn't exist.

What actually works is a hybrid approach:

1. First, search the product database (semantic or keyword)
2. Retrieve the relevant products (not all2,000 of them — just the 5-10 that match)
3. Inject those product descriptions into the LLM's context
4. Then let the AI compose a helpful, accurate response

When I got this pipeline right, something magical happened. The conversations felt better than talking to a human sales rep. The AI knew every product spec, never got impatient, and could compare options instantly. I was genuinely impressed — and I built the thing.

The "website for robots" idea

This got me thinking. Right now, websites are designed for humans — HTML, CSS, buttons, filters. But what if every e-commerce site also had a machine-readable layer? An API endpoint that describes: here are my products, here's how to search them, here's how to add something to a cart, here's how to place an order.

Think of it as a version of your store built for AI agents, sitting right alongside the human version.

The MCP (Model Context Protocol) standard is still early — most developers haven't touched it yet, and the spec can feel abstract. But the core idea resonated with me: a universal way for AI agents to interact with external tools and services.

Why I built my own sync layer

When I started implementing this for real stores, I hit the wall that every e-commerce developer knows: legacy platforms have terrible search APIs.

Try doing semantic search through Bitrix's REST API. Or getting meaningful product recommendations from a10-year-old WooCommerce instance. It's painful.

So I made a decision: sync the product catalog into a local PostgreSQL database via Prisma, generate embeddings, and run all search and matching logic there. The legacy CMS stays untouched — it still handles orders, inventory, and admin. But everything related to product discovery, search, preferences, and AI interaction lives in a modern layer.

This gave me:

• Semantic search with embeddings — "something like a black t-shirt but more casual" actually returns useful results
• Persistent customer preferences with confidence scoring — the agent remembers your size, favorite brands, preferred delivery address, and payment method across sessions. Each preference has a confidence score, so inferred data doesn't override explicit choices.
• Cart management — including multi-store carts, line-number references ("remove item 2"), and choice-from-search ("add option 3to cart")
• Two order paths — cart-based checkout (add items → submit cart) and direct order creation (skip the cart, specify items directly). Both enqueue export to the store's native admin via BullMQ.
• Automatic post-purchase learning — after every order, the system extracts delivery preferences, payment methods, sizing info, and store usage patterns. The experience gets better with every purchase.

The adapter pattern is key. Right now I ship a Bitrix adapter, but the architecture means you can plug in Shopify, WooCommerce, Magento, or anything else without touching the MCP layer.

The gap nobody is filling

Here's what I noticed: the big players — Shopify, Amazon, Google — are all building AI commerce features, but only for their own ecosystems. If you're a Shopify Plus merchant, great, you'll get AI features eventually. If you're running a mid-sized store on Bitrix, OpenCart, or a custom CMS? You're invisible.

There are millions of small and mid-sized e-commerce stores running on legacy platforms that will never get native AI integration from their CMS vendor. That's the gap.

RiserFlow is my attempt to fill it — an open-source MCP server that gives any e-commerce store an AI-native interface, regardless of what platform it runs on.

What the MCP server actually does

Here's the actual tool set the plugin exposes to any MCP-compatible AI agent:

Core tools

-🔍 catalog_search_products — the primary entrypoint. Semantic search over the synced catalog. But here's the interesting part: before searching, it auto-loads the customer's profile and enriches the query with their known preferences (size, brand, price range). If the search returns nothing, it automatically retries with relaxed filters. The agent doesn't need to ask "what's your size?" if it already knows.

• 🛒 catalog_cart_add — add items to cart by productId or by choice number from the last search ("add option 2" → resolves to the actual product). Supports multi-store carts.

• 🛒 catalog_cart_update / catalog_cart_remove / catalog_cart_get / catalog_cart_clear — full cart lifecycle. Supports line number references ("remove item 1" resolves to the correct lineKey from the cached cart state).

• 📦 catalog_checkout_submit — submit the current cart as one or more orders, grouped by store/integration. Handles delivery, payment, and customer details.

• 📦 order_create — direct order creation with explicit items (bypasses cart). Creates the order in the local DB and enqueues export to the store's backend via BullMQ.

-👤 customer_profile_get — retrieve the customer's profile and all remembered preferences.

• 🧠 customer_preference_save — explicitly save a preference (size, brand, currency, language, delivery address). Supports confidence scoring and source tracking (explicit vs. inferred vs. purchase-derived).

What happens under the hood

The plugin does a lot of work the AI agent never sees:

Automatic domain detection. When a user searches for "black running shoes size 42", the system detects this is a shoe query, pulls the user's saved shoe size from preferences, and enriches the search — all before the query hits the database.

Post-purchase learning. After every order, the system automatically extracts and saves preferences: delivery address, payment method, favorite store, apparel/shoe sizes detected from item names, and store usage patterns. The2nd order is smarter than the 1st.

Confidence-scored preferences. Every saved preference has a confidence score (0–1). Explicitly stated preferences ("my size is M") get1.0. Inferred ones ("they ordered an M last time") get ~0.72. The search enrichment only uses preferences above a threshold.

Stateful identity resolution. The plugin maintains an in-memory identity graph — it remembers which sessionToken maps to which shopId, userId, and customerId across tool calls. Guest users get auto-generated session tokens that persist to disk. This means the agent doesn't need to pass identity params on every call.

Multi-provider architecture. One plugin instance can talk to multiple backend providers (different stores, different auth schemes). Provider configs support API key, bearer token, or no auth, with routes configurable per provider.

Production considerations

• Multi-tenancy — one server instance, multiple stores, isolated data
• Idempotency — safe retries via idempotencyKey, no duplicate orders (critical when AI agents retry failed tool calls)
• Adapter pattern — swap out the e-commerce backend without touching MCP logic. Currently ships with a Bitrix adapter.
• Trilingual — auto-detects Russian, English, or Spanish from the user's query and responds accordingly
• PII masking — customer emails and phones are masked in agent-visible responses
• Memory management — in-memory caches auto-prune after 12 hours or 500 entries ## Why open source?

I plan to monetize through optimization services and cloud hosting. But the core server is open source because:

1. I want to share what I've learned. The hybrid search approach, the sync architecture, the adapter pattern — these patterns should be reusable.
2. I want this format to spread. The more stores that expose an MCP-compatible interface, the closer we get to a world where AI agents can shop on your behalf across any store — not just Amazon.
3. I believe we're heading toward "websites for robots." Just like we have robots.txt and sitemaps for search engines, we'll eventually have standardized machine-readable commerce endpoints. MCP might be the protocol that gets us there.

Try it / contribute

The repo is here: github.com/riserlabs/riserflow

There's a video demo showing a full flow — from product search to order placement through an AI conversation: https://www.youtube.com/watch?v=MyzaVotgMp4

I'm looking for:

• Feedback on the architecture
• Contributors who want to build adapters for Shopify, WooCommerce, or other platforms
• Store owners who want to try it with their catalog

If you've been thinking about how AI agents will interact with e-commerce — or if you're just tired of your CMS's search API — I'd love to hear from you.

---

I'm a solo developer building AI-native commerce tools. This is my first post on dev.to — happy to answer any questions in the comments.