The Model Context Protocol (MCP) is fast becoming the way AI assistants call external systems — the standard interface an agent uses to read your data and, increasingly, act on it. Most platforms will bolt an MCP server on later, as a project. VBWD ships one in the core. Any commercial platform you build on VBWD is agent-callable out of the box, which in the agent era is less a nice-to-have and more the thing that decides whether the fastest-growing sales channel can see you at all. Here's how it works and how to set it up.
MCP is a protocol that lets an AI assistant — ChatGPT, Claude, an autonomous shopping agent — connect to an external system and use its capabilities: query a catalogue, check a price, look up availability, and increasingly place an order. Think of it as the API built for a machine consumer rather than a human browsing a page.
On VBWD, that server isn't an add-on you integrate. The MCP plugin exposes an endpoint at POST /api/v1/mcp, and it's part of the platform. Enable it and your instance can be connected to by an AI agent. Because it sits on the same backend as your storefront, admin and mobile apps, the agent talks to the same source of truth the rest of your product uses — not a separate feed you have to keep in sync.
Exposing your system to autonomous third parties sounds terrifying until you see how it's constrained, and two architectural facts do the heavy lifting.
Reads ride the search seam — which refuses to expose people. The MCP server's reads go through VBWD's search seam (a provider registry), and that seam is built to refuse, at the architecture level, to make user records and invoices queryable. So an agent can ask "what products match this, and what do they cost" but cannot be talked into surfacing your customers or their invoices. An entire category of "we accidentally exposed customer data to an AI" mistakes is closed off by design, not by a checklist you have to remember.
Prices are authoritative. The catalogue an agent reads over MCP is priced by the same pricing engine your checkout uses. That matters more than anything, because an agent quoting a stale or wrong price is worse than an agent that never found you — it makes a promise your checkout won't honour. On VBWD the number the agent sees is the number the customer pays.
The short version, from a working install:
/api/v1/mcp endpoint.Three, stated plainly. First, the agent-commerce standard is still converging — MCP is the leading interface, but conventions around agent identity, mandates and settlement are pre-standard, so expect to adapt as they firm up. Second, exposing an endpoint to autonomous callers means you want rate limits, spend/scope ceilings and monitoring from day one — the search seam protects your customer data, but you still own operational hardening. Third, "agent-callable" makes you discoverable by agents; it doesn't make you chosen — the selection logic lives inside models you don't control. Being present is necessary, not sufficient.
MCP is turning into the interface through which AI assistants use the world's software, and for anyone selling something, being callable over it is becoming as basic as being crawlable by Google once was. VBWD ships the MCP server in the core, on the same backend as everything else, with the search seam keeping customer data unreachable and the pricing engine keeping quotes authoritative. You don't build the agent interface; you enable it, scope it, and point an agent at it. In a channel that barely existed two years ago and is growing fast, "already agent-callable" is a real head start.
VBWD ships an MCP server in the core, so any commercial platform you build on it is agent-callable out of the box. It's free for commercial use below a defined revenue threshold, so you can start today at zero platform cost. Running an enterprise or a serious store and want it installed, migrated and made agent-ready? Request an enterprise installation at vbwd.cc/contact. Explore: plugins · architecture · docs.