v0.22.0 gives admins a curated skill catalog, fleet-wide visibility into the AI tools running on employee machines, and stronger enterprise controls over MCP servers.
The Obot Platform v0.22.0 release is out. A lot of our recent conversations with teams have circled back to the same problem, which we’ve started calling the “client zoo”: a single company has users spread across many different AI clients and coding agents, each with its own configuration model, its own skills directory, and its own way of attaching MCP servers. Skills have the same problem a level deeper. There’s no real standardization in how skills are authored, so teams end up duplicating effort and shipping skills that aren’t very good. Admins can’t see what’s safe, what’s burning tokens, or where the obvious efficiencies are.
This release is a first step at solving that. v0.22.0 adds two major capabilities aimed at the AI clients and coding agents that users actually run on their local machines:
Admins curate a catalog of skills in Obot, govern access with dedicated Skill Access Policies, and users install those skills into their local AI clients and coding agents with the new obot skills CLI command.
obot scan gives admins fleet-wide visibility into the AI clients, MCP servers, and skills actually installed across their users’ machines.
It also ships several MCP enterprise controls: managed image pull secrets for private registries, external secret integration for MCP servers, an OAuth inspector for diagnosing remote MCP authentication, user-defined headers for multi-user MCP servers, and a new generic model provider that replaces the dedicated Ollama provider.
Centrally Managed Skills for Local Agents
Skills are reusable, structured instructions that an agent can discover and install to expand what it can do. They’re packaged as directories with a SKILL.md file and follow the agentskills.io standard, which is gaining adoption across the AI client and coding agent ecosystem. Having a standard helps, but it doesn’t solve the operational mess. In a typical org, every user is grabbing skills from different repos, sharing them over Slack, or hand-editing config files, and nobody knows what’s actually running.
v0.22.0 puts that under a single control plane.
Admins point Obot at one or more GitHub repositories as Skill Sources. Obot indexes every SKILL.md it finds and re-syncs on a schedule. Access is governed by Skill Access Policies that grant specific users or groups access to individual skills, an entire source repository, or every skill. Policies are additive and live alongside the Model Access Policies and MCP server access policies that already exist, so the workflow will feel familiar even though the policy types are technically distinct.
Users discover and install skills with the new obot skills command in the Obot CLI. It can be used two ways:
Directly from the terminal, to search the catalog and install a skill into the user’s local agent.
From inside the agent, once Obot’s bootstrap skill set is installed.
The second path is handled by obot setup. It walks the user through an OAuth login against a specific Obot instance, detects the major AI clients and coding agents that follow the ~/.agents convention (Cursor, VS Code, Codex, and others) plus Claude Code, which uses its own directory, and installs four small skills: a top-level obot skill that tells the agent how to use the CLI, plus the /obot-scan, /obot-skills-install, and /obot-skills-search slash commands. After that, users can search and install skills from inside their agent without touching the terminal again.
There are no API keys to hand around. Authentication is OAuth per Obot instance, and CLI tokens are stored in the OS keychain. The user UI also has a dedicated Obot CLI page and a Skills page that lists the exact set of skills a given user is allowed to install based on the policies the admin configured.
Fleet Visibility with obot scan
Centrally managed skills only solves half the visibility problem. The other half is the gear already on users’ machines: every AI client a user has installed, every MCP server those clients are wired up to, every skill and plugin sitting in someone’s home directory. Today, admins typically figure that out by asking around, which doesn’t scale and rarely gives them an accurate picture.
obot scan is a new CLI subcommand that addresses this directly. It walks the user’s home directory, parses the configuration for every AI client it recognizes (Claude Code, Claude Desktop, Codex, Cursor, Goose, Hermes, Openclaw, Opencode, VS Code, Windsurf, Zed), and submits a single envelope to the Obot backend describing what it found: which clients are installed, which MCP servers each one is configured to talk to, and which skills and plugins are present on disk. Files over 1 MiB are recorded by path only, without uploading content.
Admins get a new Device Management area in the admin UI. The Dashboard shows distinct device and user counts and ranked donut breakdowns of the top AI clients, MCP servers, and skills across the fleet over a configurable time window. From there, admins drill into per-device scan history, per-MCP-server occurrence lists (grouped by a content hash so the same logical server collates across users), and per-skill occurrence lists. Auditors get read-only access to the same views.
This is just the start. In upcoming releases we’ll be turning fleet scan data into more actionable insights: usage signals that drive access policies and cost optimization, ways to enforce policies locally rather than just observe them, and tighter loops into the deployment, auditing, and management of MCP servers running on users’ machines (including making scans happen on a regular cadence rather than ad hoc).
Managed Image Pull Secrets for MCP Servers
Plenty of teams run their MCP servers from a private registry: GHCR, Docker Hub Pro, a self-hosted registry, or Amazon ECR. v0.22.0 lets admins manage the image pull secrets for those registries from the Obot UI.
Two secret types are supported. Basic secrets cover registries that accept a username and password or token. ECR secrets cover Amazon Elastic Container Registry, and they work a bit differently: Obot never stores AWS access keys. Instead, the Obot controller uses Kubernetes service account OIDC federation. It requests a projected service account token, exchanges it with AWS STS via AssumeRoleWithWebIdentity, calls ECR’s GetAuthorizationToken, and writes the resulting Docker config JSON secret into the MCP namespace. A controller refresh runs every six hours by default, so the secret stays valid without manual rotation. The UI surfaces the trust policy and ECR IAM policy Obot needs you to attach to the role, plus a Test button that verifies the credential can pull a real image.
If you already configure pull secrets through the Helm chart’s mcpImagePullSecrets value, that path continues to work and the UI becomes read-only. The two modes are mutually exclusive on purpose.
External Secret Integration for MCP Servers
For organizations standardized on Vault, AWS Secrets Manager, or the External Secrets Operator, having Obot prompt users for credentials and then store them itself isn’t the right shape. Those teams already have a pipeline that syncs secrets into Kubernetes Secrets, and they want Obot to reference those Secrets rather than take a copy.
v0.22.0 adds secret bindings on MCP catalog entry env vars. A catalog entry can declare that a particular environment variable should resolve from a named Kubernetes Secret and key, and at deploy time Obot writes a secretKeyRef into the MCP server pod spec instead of resolving the value itself. The secret value flows from the external store to the Kubernetes Secret to the container, exactly the way Kubernetes intends. Obot never sees or stores it.
In v1, secret bindings can only be declared in git-managed catalog sync sources, not through the UI. That’s intentional: bindings get code-reviewed and version-controlled, which matches how teams using Vault and ESO already work.
OAuth Inspector for Remote MCP Servers
Remote MCP servers that sit behind OAuth are notoriously hard to debug. Different servers expose different metadata, the handshake has several distinct steps that can each fail silently, and it’s often unclear whether the issue is on the server, the client, or somewhere in between.
v0.22.0 adds a set of tools to diagnose these flows directly from the Obot UI. The MCP server detail page surfaces the OAuth metadata Obot discovered for the server (authorization endpoints, supported scopes, client info) and exposes a walk-through debugger that steps through the OAuth handshake one stage at a time, making it clear where a flow is breaking. Users can also re-trigger the OAuth flow for a server when a token has gone stale or the server’s OAuth configuration has changed, instead of deleting and re-adding the server.
User-Defined Headers for Multi-User MCP Servers
Previously, the only way to require per-user configuration on an MCP server was to deploy it as a single-user server, which spins up a separate pod for every user. In a large org, that wastes a lot of capacity when the only thing varying between users is a single credential.
User-defined headers let admins deploy one shared multi-user server and have each user supply their own credential (or other per-user value) as a header that Obot passes through on every request. This only works when the MCP server implementation reads the header itself, so it’s intended for servers designed with that pattern in mind. When it applies, it collapses a per-user fleet of pods down to one.
Generic Model Provider Replaces Ollama
The dedicated Ollama model provider has been replaced with a generic OpenAI Responses-compatible model provider. The generic provider works with Ollama, LiteLLM, and any other gateway that exposes an OpenAI-compatible Responses endpoint. If you were using the Ollama provider, reconfigure it under the new Generic provider with the same endpoint.
Additional Improvements and Upgrade Notes
This release also includes per-server MCP startup timeouts that admins can tune on individual catalog entries, separate resource request defaults for agents and remote MCP servers, configurable dynamic OAuth client expiration, support for sourcing the custom encryption key from an existing Kubernetes Secret, and a per-provider log level for model providers. See the release notes for the full list.
One upgrade callout worth flagging: legacy chat functionality has been removed in v0.22.0, along with a number of legacy APIs, configuration parameters, and the old triggers, knowledge, and workspace systems. If your deployment relies on any of those, check issue #6680 for the exhaustive list before upgrading. The Helm chart’s extraEnv and extraEnvFrom values have also been removed; move those settings into the existing config: block.
Get started
The fastest way to try v0.22.0 is to follow our installation guide. If you’re already running Obot, read the upgrade notes above before bumping the version.
If you’d like to talk through how the new skill management and fleet visibility features fit with your team’s setup, or you’re seeing a flavor of the client zoo we haven’t addressed yet, email info@obot.ai. We’d like to hear what you’re running into.
