NextAI-SEM: The AI Commerce Platform I Built, With an MCP Server Inside
NextAI-SEM is the e-commerce and search-marketing platform I've been building since March 2026. It runs online stores and lead-generation sites for our clients, and this blog runs on it too. Each client gets an independent install with its own database, and updates roll out in batches.
The stack
- a PHP 8.3 API on my own framework;
- a React and TypeScript admin;
- a static Next.js 16 storefront, rebuilt when content changes;
- a Python FastAPI service for the sales chat agent;
- MariaDB.
The storefront is static on purpose. I wrote about why in Why Next.js Static Generation Belongs at the Core of High-Traffic Websites: pages are fast, cheap to serve and hard to break.
AI where it earns its place
The platform uses Gemini and Claude for product descriptions, page content and keyword work, detects search intent for Google Ads, and generates llms.txt files so AI assistants can read a store cleanly.
The most important lesson: AI output is untrusted input. An AI pipeline writes HTML into the database verbatim. If a prompt injection gets into that HTML, it ends up as script in the static page every visitor loads. Today every HTML field the storefront renders goes through a sanitizer, including the ones I used to consider "trusted backend" content.
A 53-tool MCP server
Every install has an MCP server that lets AI assistants manage the store: products, categories, pages, blog posts, images, chat knowledge, leads and lead forms, proposals, product add-ons and site rebuilds.
- Each user has their own token, stored only as a hash.
- Tools appear only when their module is enabled, so the assistant never sees what it can't use.
- Schemas are strict, and every write defaults to a dry run.
- Every call, including dry runs and failures, is written both to a JSON log and to a database table.
- The MCP test suites hold more than 590 assertions.
One trap deserves its own paragraph. The admin uses a rich-text editor that stores content twice: as editor state for editing and as HTML for the storefront. Agents write HTML. If the admin can't rebuild its editor state from that HTML, it opens an empty editor, and the next time a person presses Save, the content is gone. No error anywhere, and the data loss happens later, by a human hand. So every field an agent may write must have a tested HTML fallback in the editor, and a field without one stays read-only for agents.
A sales chat agent that asks before it keeps anything
The storefront's chat agent runs on Claude Sonnet with streaming, prompt caching and a fallback model. It has exactly one tool: submit an enquiry. The tool's schema is generated from the site's published lead form, so the agent collects precisely the fields the owner asked for.
It refuses to submit without recorded consent, asked word for word, and it won't create a second lead in the same session. Rate limits apply per IP and per visitor, and the service logs no visitor data. The product knowledge it answers from comes from the catalogue and from knowledge entries that an assistant can update over MCP.
Keeping a fleet of sites in step
Sites can share Google Ads keyword data through a federation protocol. Each message is signed with HMAC-SHA256 and carries a timestamp and a single-use nonce, so a captured request can't be replayed. Adding a site to the shared scheduler is one line in a registry file, and the build refuses to publish a catalogue that has suddenly collapsed, so a bad import can't take a store live with empty shelves.
More of what I build is in my AI and MCP portfolio, and the safety rules behind all my MCP servers are in How I Let AI Agents Write to Live Business Data.