github obot-platform/obot v0.26.0
on GitHub

2 hours ago

We're excited to announce the v0.26.0 release of the Obot Platform. This release replaces composite MCP servers with virtual MCPs, adds an in-app MCP tester, and adds opt-in product analytics.

Important

Existing installations should not upgrade to this release. vMCPs do not fully support upgrades in v0.26.0, and upgrade support will follow in a patch release. Only net new installations should install v0.26.0. See #7802 for details.

Big Updates

Virtual MCP Servers

Virtual MCPs (vMCPs) are now the resource used to expose newly created MCP endpoints. A vMCP holds one or many catalog components, so a single server and an aggregation of several now use the same resource and the same connection model. Standalone and composite servers remain available for migration compatibility.

Each component stores a snapshot of its catalog entry instead of resolving against the live entry at runtime. A catalog edit, a failed sync, or a deletion no longer changes or stops a running server on its own. Drift and missing sources are reported, and a snapshot changes only through an explicit, validated upgrade. Each component also carries a configuration policy that classifies every input as preconfigured, provided at connection time, or ignored.

Access and tool grants come from additive user and group profiles on the vMCP. A profile can grant every tool or map specific tools per component, and a user connecting to the vMCP can narrow their grant but never widen it. Administrators can create vMCPs that other users consume, and a user can create a personal vMCP from catalog entries they already have access to, but cannot share it.

MCP Tester

Users can now connect to any vMCP server they have access to and exercise it directly inside Obot. With the tester, users can chat with the configured default model and make real tool calls against the server. An inspector lists the server's tools, prompts, and resources so they can be viewed and invoked individually.

Conversations are ephemeral and are not stored. Chat traffic both show up in the audit logs like any other activity.

Detached Catalog Entries

Removing an entry from a Git-backed MCP catalog no longer deletes the servers that people have already deployed from it. When a sync removes an entry that still has connections, Obot marks that entry detached and keeps it in a read-only state, so the deployments that depend on it keep working. An administrator can then accept ownership of a detached entry, which converts it into an Obot-managed entry they can edit. If the entry later reappears in the catalog source, the sync reports the conflict instead of silently overwriting the version Obot is holding.

Note

The AntV Charts, Brave Search, Browserbase, Chroma Cloud, MarkItDown, and Playwright MCP servers have been deprecated and will be removed from a future release. Update instructions will be provided one minor-version release prior to their removal. See #7626 for details.

Product Analytics

Obot will now report anonymous product usage data; this is disabled until an administrator explicitly opts in. Consent is stored installation-wide as an explicit three-state value, undecided, granted, or declined, and only an Owner or Admin can read or change it.

Administrators are asked once and can change the answer later. In deployments where product analytics is force-enabled through configuration, the consent API is not exposed at all.

Improvements

  • Token spend graphs have been added to the usage and dashboard pages, and spend is now reported for Bedrock and Azure Entra models.
  • Agent Auth Scopes are now revoked rather than deleted. LLM and MCP audit logs record the API key ID and name behind each request, can be filtered by key, and identify revoked keys.
  • A new CLI command validates catalog YAML before you commit it, and a system mcp validate command checks a configured MCP server.
  • Administrators can cap CPU and memory requests and limits for MCP server scheduling from the UI.
  • The MCP servers page loads faster, and the app navigation has been reworked.
  • Obot now emits structured JSON logs through slog.
  • Group listings are paginated, and catalog entry forms support option lists for environment variables and headers.
  • Device scan submissions are compressed on the wire and cleaned up on a retention schedule, and auditors have read-only access to MDM configuration routes.
  • The audit logger no longer pre-allocates 2GB for its buffer.
  • The app-facing Basic user role is now called Standard.
  • Controller leader election is held in a SQL table instead of a Kubernetes Lease.

Security

One security advisory is published alongside this release.

GHSA-6fwv-3h4c-37j9: Authorization bypass through the composite MCP connect route (High). The fix for GHSA-vw82-7fv8-r6gp guarded the /mcp-connect/ route but not the sibling composite route, which reaches the same gateway handler. Any authenticated user, including one with the Standard role, could therefore connect to and use MCP servers through that route without the access control rules that were meant to gate them. This affects v0.21.1 through v0.24.1 and was fixed in v0.25.0. Note that upgrading in response to GHSA-vw82-7fv8-r6gp does not by itself cover this issue, because the fix that advisory describes is the incomplete one. If you are still running v0.24.1 or earlier, upgrade. Reported by @arpitjain099.

Upgrade Notes

Okta users on versions earlier than v0.19.0 must upgrade to v0.25.x first. This release removes an Okta group migration that has been present since v0.19.0 and that pre-v0.19.0 installations still need. Upgrade to v0.25.x so that migration runs, then move to v0.26.0. See #7779 for details.

Replicas in an HA deployment can briefly fall behind during the rolling upgrade. kinm watches now use Postgres LISTEN/NOTIFY instead of polling every two seconds, which cuts idle database load from watches by roughly 15x and propagates a change from one replica to another in tens of milliseconds rather than up to two seconds. During the first rolling deploy of this version, a replica that has already upgraded does not hear from a replica still running the previous version, so it can take some additional time to upgrade. This happens once, closes on its own, and needs no action. Each replica also opens one additional Postgres connection, and connection poolers running in transaction mode do not carry LISTEN, in which case kinm detects it on connect and keeps the previous polling behavior. See #7737 for details.

What's Changed

New Contributors

Full Changelog: v0.25.1...v0.26.0

Check out latest releases or
releases around obot-platform/obot v0.26.0

Don't miss a new obot release

NewReleases is sending notifications on new releases.

Get notifications