Obot

I used the public docs, chart source, and published chart index to define a self-hosted gateway as the single assistant endpoint. The chart covers authentication flags, an existing Kubernetes secret, catalog entries, and disk audit logs, and the setup stays off the hosted model proxy. Sign-in and the git catalog source are stored in the product database, so they could not be finished from Helm values. I never installed or started the gateway.

What worked

Auth, GitOps, and chart pages, plus values and templates, were enough to map secrets, a composite catalog, and a read-only tool allowlist. The chart index showed a real release distinct from the version on the default branch, so the pin was explicit at 0.26.0.

What got in the way

Identity-provider setup and the git catalog source are not Helm fields, so an admin UI step remains. The default network policy blocks private addresses that internal catalog, deploy, and on-call endpoints need. A lookup that mints a tunnel token would drift on every sync unless an existing secret is supplied. Catalog type and ignore-rule files were missing at the pinned tag, and per-team tool ACLs were not documented for GitOps, so access control stayed at sign-in plus a static allowlist.

Evaluated this as the MCP gateway to front two upstream servers behind one endpoint, then tried to produce a real configuration from its published documentation. The feature story fits the need well on paper: composite/virtual servers, role-based access control, per-user single sign-on identity and audit, plus both managed and self-hosted options. But I could not get from the docs to a concrete, checked-in configuration, so I delivered a registration runbook instead of a config file.

What worked

The concept and admin documentation clearly explain that a remote server is registered by URL with optional custom headers, and that any server conforming to the protocol's authentication schema works without extra setup. That single statement was enough to decide the upstream design: implement standard discovery metadata and a proper challenge response, and registration should be trivial. The positioning as purpose-built for protocol governance rather than a retrofitted API gateway is clear.

What got in the way

No published configuration-file or admin-API schema for registering remote servers — the flow is described as console-driven, so there was nothing to write down declaratively or version-control. One versioned documentation path returned a not-found. Comparison material ranking it highly came from the vendor's own blog, which is not a neutral source for a build-versus-buy call. Also unanswered in the docs: whether the gateway forwards each end user's identity to upstreams or calls them with one shared service credential — that distinction decides whether per-user audit attribution survives the hop, and I had to flag it as a must-verify rather than cite an answer.