Obot Platform v0.26.0 introduced virtual MCP servers (vMCPs) and they are one of the biggest changes we have made to how Obot handles MCP servers. A vMCP is one MCP endpoint that contains one or more MCP servers from your catalog. It replaces both standalone and composite servers as the way Obot exposes MCP servers to users and agents. v0.26.0 also rebuilt much of the Obot UI around vMCPs, and v0.26.2 adds upgrade support: existing v0.25.x installations can upgrade and have their MCP servers migrated to vMCPs automatically.
This is the feature we’re most excited about this cycle. It makes the whole platform simpler to reason about while giving administrators more control than they’ve ever had. This post covers what a vMCP is, why we built it, and what it looks like to create and use one.
Why we replaced servers and composites
Before v0.26.0, how you connected to an MCP server in Obot depended on how it had been created. A single-user server, a multi-user server, and a composite server were separate resource types. Each had its own rules for configuration, access, tool restrictions, and updates. Composite servers did some of what vMCPs do now: they let you combine a few servers behind one URL and trim their tools. But they played second fiddle to regular servers. They were harder to set up and easy to miss entirely.
vMCPs replace all of that with one model. A vMCP with a single server in it is what used to be a standalone server. Put five servers in it and you have what used to be a composite. Both work the same way: one connection URL, one access model, one set of rules for updates. Combining servers is no longer a separate feature you have to go find. You just drag in as many as you need. vMCPs are also the first thing in the navigation now, and they’re what every user connects to.
This has been the most requested capability from customers and OSS users. Combining servers is a big part of it, but not all of it. Teams want the same underlying set of servers exposed with different profiles for different groups. They want to lock in tool names and descriptions so what the model sees is exactly what they approved. And they want to drop a single URL into something like Claude’s managed configuration and have it resolve to tools scoped to whoever is connecting. Composites could cover some of that, but we found that many customers didn’t know they existed or didn’t understand them. That’s why vMCPs are front and center, with a visual drag-and-drop editor for building them.
What a vMCP is made of
A vMCP has a few parts:
Components. Each component is an MCP server from the catalog. It can be a remote server Obot proxies to or a server hosted by Obot. When you add a component, Obot stores a snapshot of that catalog entry inside the vMCP.
Configuration policies. For every configuration field a component declares, the vMCP’s creator decides who supplies the value.
Tool settings. Per component, you choose which tools are exposed and can rename them, rewrite their descriptions, or add a prefix to avoid name collisions between components.
Profiles. Profiles grant users and groups access to the vMCP and to specific tools within it.
Instances. When a user connects, Obot creates a vMCP instance for them that holds their own configuration values and credentials.
Clients connect to a single streamable HTTP endpoint:
https://your-obot-instance/mcp-connect/{vmcp-id}
Any MCP client that supports remote servers can use that URL. On the first connection, Obot creates the user’s instance and prompts for any values that user needs to provide, or for upstream OAuth if a component requires it.
Building a vMCP
The vMCPs page is now the first item under AI Resources in the sidebar. Create vMCP opens a designer: the MCP servers you can access are listed on the right, and you drag them onto the canvas to add them as components.
Here is a vMCP we built for this post, called “Engineering Research.” It combines DeepWiki for questions about public repositories, Context7 for library documentation, and Elasticsearch for searching the team’s logs and operational data.
Clicking a component lets you modify its tools, change its configuration, or remove it. The configuration step is where vMCPs really shine.
Configuration policies: who supplies each value
Every configuration field on a component gets one of three policies:
Preconfigured. The vMCP creator sets the value once, and every connection uses it.
Provided at connection. Each user supplies their own value when they connect. It is stored with that user’s instance.
Ignore. The vMCP neither accepts nor supplies a value for the field.
Required fields must be Preconfigured or Provided at connection. Optional fields default to Ignore, so a user can never inject configuration that the vMCP’s creator did not explicitly allow.
For the Elasticsearch component in our example, we preconfigured the Kibana URL and left the API key to each user:
The result is that every engineer who connects is pointed at the company’s Elastic deployment without having to know its URL, and each one authenticates with their own API key, so Elastic’s own permissions apply to every query. The administrator set it up once, in one place. That’s exactly the kind of setup we wanted to make easy.
These policies also determine how Obot runs each component. Catalog entries no longer declare whether a server is single-user or multi-user. Obot derives it from the policies you set:
A component whose fields are all Preconfigured or ignored can run as a single shared deployment.
User-provided headers, like the Elastic API key above, stay isolated per connection but do not require separate deployments.
Any other user-provided value, such as an environment variable for a hosted server, causes Obot to run a separate deployment of that component for each user.
Force single-user gives each user their own deployment regardless.
Obot makes this decision per component, so one vMCP can mix shared and per-user deployments. Values that the creator preconfigures are stored as credentials, not on the vMCP object, and in Git-managed setups they can come from a Kubernetes Secret through a secretBinding.
Profiles: who gets which tools
Access to a shared vMCP comes from profiles. A profile names users, groups, or all Obot users, and grants either every tool on the vMCP or a specific set of tools per component.
In this example, platform admins get all three components, while the “All engineers” profile grants DeepWiki and Context7 but not Elasticsearch. Both groups use the same URL, and each user sees only the tools their profiles grant. No more standing up a second server just to give a different team a different slice of tools.
Tool access is applied in three layers:
Component tool settings define the most a vMCP can expose. A tool disabled here is unavailable to everyone.
Profiles grant all or part of that set. Profiles are additive: if a user matches several, they get the union of the grants. There is no deny rule, so a narrow profile cannot take away a tool that a broader one grants.
The user’s instance can narrow that union further. A user who only wants a handful of tools in their client can turn the rest off, but they cannot enable anything outside their grant.
If a user leaves a group or a profile is narrowed, Obot recalculates their grant, so existing connections lose tools the user no longer has.
Shared and personal vMCPs
Only administrators can create vMCPs that other people use. A new shared vMCP starts with a default profile that grants administrators access to everything, and the administrator then adds profiles for the users and groups who should have it. The people using a shared vMCP do not need access to the underlying catalog entries.
Any user can also build a personal vMCP from the catalog entries they already have access to. A personal vMCP is visible only to its owner and cannot be shared. This is a convenient way for an individual to combine the servers they use every day behind one URL in their client. If the owner later loses access to one of those catalog entries, Obot removes that component from their personal vMCP.
Snapshots: catalog changes no longer reach running servers on their own
When you add a component, the vMCP stores a snapshot of that catalog entry, and the running component uses the snapshot instead of the live entry. In practice:
Editing a catalog entry does not change existing vMCPs. Obot shows that an update is available, and adopting it is an explicit action on the vMCP.
If a catalog sync fails or an entry disappears from a Git source, existing vMCPs keep working.
Deleting a catalog entry is not an emergency stop. To stop a server, you disable or delete the vMCPs that use it.
That last point is a deliberate tradeoff. Snapshots make deployed behavior stable and reviewable, but they also mean an outdated definition stays active until an administrator updates or deletes the vMCP. Obot reports drift and missing sources so they are visible.
This works together with another v0.26.0 change: removing an entry from a Git-backed catalog no longer deletes servers people have already deployed from it. The entry is marked detached and kept read-only, and an administrator can accept ownership to convert it into an Obot-managed entry.
Testing a vMCP inside Obot
v0.26.0 also added an MCP tester. Next to Connect, a vMCP has a Test vMCP action that walks you through any required configuration and then opens a chat with your default model, connected to that vMCP. The model can make real tool calls, and an inspector lists the vMCP’s tools, prompts, and resources so you can call them individually.
It’s a surprisingly satisfying loop: build a vMCP, click Test, and watch the model use it a few seconds later. It’s also the quickest way to check that a vMCP’s configuration behaves the way you expect before pointing Claude Code, Cursor, or VS Code at it. Tester conversations are not stored, but the tool calls they make appear in the audit logs like any other activity. Audit logs can also be filtered by vMCP.
A UI rebuilt around vMCPs
vMCPs are the centerpiece of a broader UI rework in v0.26.0. The navigation now uses one shared sidebar for every role instead of separate app and administration sections, and what you see depends on your role. vMCPs, MCP Servers, Skills, and Models are grouped under AI Resources. Audit logs, usage, and device inventory sit under Operations, followed by Identity & Access and Platform. Old URLs redirect to their new locations.
The vMCPs page offers grid and table views, filters by connection state, and one-click setup buttons that connect all of your vMCPs to supported clients at once.
Upgrading and GitOps
v0.26.0 was for new installations only. v0.26.2 is the upgrade release for existing v0.25.x installations. On startup, it creates a vMCP for every MCP server that an access control rule exposes, including composites, and converts the existing access into vMCP profiles. The upgrade does not grant any user or group new access. Installations with broad access rules will see many new vMCPs; administrators can review them and delete any that are no longer needed.
If you maintain MCP catalogs in Git, the catalog schema has changed. Environment variables and headers are now one config list, serverUserType is gone, and composite entries are replaced by vMCP definitions, which can now be synced from Git as well. The Obot CLI includes obot mcp convert-catalog and obot mcp validate-catalog to update existing catalogs, plus obot mcp generate-vmcp-catalog to generate definitions for migrated composites. Catalog-synced vMCPs are read-only in the UI.
The v0.26.2 upgrade also needs extra steps for Kubernetes deployments that run more than one replica. The v0.26.2 release notes have the full procedure, and the vMCP documentation covers the feature in detail.
What’s coming
vMCPs are the foundation for a lot of what we’re building next. Two things are already on the way:
Tool search and execute. Putting every tool from every component in front of a model stops working well once a vMCP grows large. Tool search and execute will let a vMCP scale to hundreds or even thousands of tools, so the model can find and call the tools it needs instead of loading all of them up front.
OpenAPI to MCP. Not every system you want to reach has an MCP server. With OpenAPI support, you’ll be able to pull APIs directly into a vMCP as components, alongside your existing MCP servers, with the same configuration policies and profiles.
Get started
vMCPs give every MCP connection in Obot the same shape: one URL, explicit configuration, and per-user tool access you control from one place. We think they’re the best way yet to put MCP servers in front of a whole organization, and we can’t wait to see what you build with them.
