AI agents are becoming a way people interact with software. A user asks Claude or an autonomous agent to "check my orders" or "find datasets about air quality," and the agent needs a way to actually reach your application to do it. The emerging standard for that is the Model Context Protocol (MCP): a defined way for an agent to discover and call the tools a system exposes. VBWD makes your instance agent-callable with a single plugin — enable it, and one endpoint turns your platform into an MCP server exposing permission-gated slices of your data and actions. This post explains what that gives you, how it stays safe, and why it was almost no new code to build.
The Model Context Protocol is a contract between an AI agent and a system that offers tools. The agent connects, asks what tools are available, and calls them with structured arguments; the system runs the tool and returns a structured result. It is, in effect, a standardised function-calling interface over the network, so that any MCP-aware agent — Claude Desktop, an autonomous agent framework — can use any MCP server without a bespoke integration. If your product speaks MCP, agents can use it out of the box.
The practical upshot: instead of building a custom integration for every AI tool your customers might use, you expose MCP once, and the whole ecosystem of MCP clients can talk to your instance.
VBWD's MCP support is a plugin that mounts a single endpoint — a JSON-RPC 2.0 interface over Streamable HTTP at POST /api/v1/mcp. When the plugin is disabled, that route does not exist; a request returns 404. Nothing is exposed to agents until you deliberately turn it on. This "off by default, 404 until opted in" posture is the right default for a capability that grants programmatic access — you opt into agent-callability explicitly, per instance, rather than shipping an open door.
Once enabled, an MCP client connects to that endpoint, negotiates the protocol, lists the tools your instance offers, and calls them. From the agent's side it is a standard MCP server; from your side it is one more plugin you enabled.
The critical design decision is what the MCP server is allowed to expose. It does not hand an agent your whole database. It exposes specific, permission-gated slices of capability — read and action surfaces drawn from the plugins you have enabled, such as shop, booking, subscription, or a catalogue — plus, where configured, an LLM tool. Each tool the server offers is bounded, and access runs through the same permission checks the rest of the platform uses. An agent can only reach what the server has been configured to offer and what the caller is permitted to see.
This is where a general safety principle of the platform shows up concretely: certain data is structurally off-limits to these read surfaces. The search seam that several of these tools ride is built to block privacy-sensitive slices — user records and invoices are not casually exposed to a general read tool. The MCP server inherits that discipline. Making your instance agent-callable does not mean making it agent-readable in full; it means offering a curated, permissioned set of tools.
The reason the MCP plugin was cheap to build is that it did not invent new access to your data — it composed access that the core already exposed as seams. Three in particular:
Because these seams were already there, the MCP plugin is mostly protocol glue — speak JSON-RPC 2.0, implement the MCP handshake, map "list tools/call tool" onto the existing registries — rather than new data access. And, true to the platform's core rule, none of it required touching the core: the core exposed the seams; the plugin consumed them. That is the payoff of the agnostic-core discipline showing up in a concrete feature — a whole new interaction model added as a plugin, with the core untouched.
Concretely, enabling MCP lets an agent do things like: browse your product or dataset catalogue, look up availability or bookings, check subscription-related information — each within the permissions of the caller and the tools you exposed. A customer using Claude Desktop could ask their agent to find and summarise items from your catalogue; an internal operator could wire an autonomous agent to your instance for routine lookups. You are meeting users where they increasingly are — inside an AI assistant — without building a separate integration for each assistant.
For a product owner, this is a distribution surface. As more of your customers work through AI agents, "we speak MCP" means your product is reachable from inside those agents by default, rather than being a website they have to leave the agent to visit.
Agent-callability is powerful, which means it deserves care. A few honest points. First, only expose what you mean to: the server offers what you configure, so treat the tool list as a security surface and keep it minimal. Second, the privacy blocks on the search seam are a floor, not a substitute for thinking — before enabling MCP on an instance with sensitive data, confirm which slices the configured tools actually reach. Third, MCP and the broader agent ecosystem are young; the protocol and client behaviours are still evolving, so treat this as a capability you turn on deliberately and monitor, not a fire-and-forget setting. Finally, an LLM tool exposed through the server consumes model calls — meter and bound it (the platform's token system is the natural way) so an agent cannot run up unbounded cost. Within those bounds, you get a standards-based way to make your product usable by AI agents with a single toggle.
VBWD turns your instance into a Model Context Protocol server with one plugin: a single JSON-RPC 2.0 endpoint, off by default and 404 until you opt in, exposing permission-gated slices of your enabled plugins plus an optional LLM tool — never your whole database, and never the privacy-blocked slices. It was inexpensive to build because it composes seams the core already published — the search-provider registry, the LLM connection manager, the plugin system — rather than inventing new data access, and it left the core untouched. The result is that as your users move into AI agents, your product is already reachable from inside them.
Enable the MCP plugin, review exactly which tools it exposes for your enabled plugins, meter any LLM tool, then point an MCP client such as Claude Desktop at POST /api/v1/mcp.