Building your MCP is a weekend. Governing what it can touch is the job.

There’s a line on Obot’s website that names where real MCP-server work lives: “Building MCP servers or Skills is simple. OAuth, security, and ops are not.” I’ve lived both halves. The first MCP server you write to let Claude reach into a real system is genuinely a weekend project. The more complex work starts the moment it’s not one server, one user, and your laptop anymore.

If “MCP server” is new to you: it’s a small adapter that lets an LLM actually do things in a system you already use, like your database, ticketing tool, or an internal API. Useful immediately. Dangerous, quietly! You can learn more about MCP at the LF Projects MCP Site.

Where the paved road ends

The MCP I’m putting behind a gateway in this post is small, sharp, and real: three tools on a lightweight health-check adapter. It already exists, and works. It already has a token that scopes what it’s allowed to see.

Here’s the wall I hit, and it’s the same wall every team hits once an MCP works well enough to want more of it:

  • Secrets everywhere. Each server carrying its own credentials, in its own file, with no one place to rotate or revoke them.
  • No access policy. Nothing between “the agent can reach this system” and “the agent can do anything this system allows.”
  • No audit trail. When someone asks what did the AI actually touch last Tuesday?, the honest answer is a shrug and a log file that doesn’t quite have what you need.
  • Shadow MCPs. The second one shows up. Then the third. Nobody centrally knows what’s talking to what.

None of that is an AI problem. It’s an ops-and-security problem wearing an AI costume, and it’s exactly the part most “AI for your business” efforts skip.

The pattern that fixes it: a gateway in front

The fix isn’t a better model. It’s the same move you’d make for any internal service that’s about to be used by more than its author: put a gateway in front of it. One control plane where you decide who and what gets through, authenticate against the identity provider you already run, log every call, and keep a registry of what exists.

For MCP specifically, that’s what Obot is. An open-source MCP gateway: hosting, registry, access control, and audit, in one place. I guide mid-market clients toward governance solutions they can actually adopt, and Obot fits both the shape of the problem and my open-source instincts. Two decades at Canonical and SUSE will do that to you.

Doing it with Obot: three surfaces working together

The mental model that made everything click, once I saw it, was that Obot decomposes what you might have expected as a single “add an MCP server” form into three complementary surfaces:

  1. MCP Catalog → Catalog Entries. The definition. You describe what your server is: name, runtime type (NPX, UVX, or Containerized), where its package lives, the credentials schema.
  2. MCP Deployments. The running instance. Obot materializes a server from a catalog entry. It’s one shared instance if you pick Multi-Tenant, or one per user if you pick Single-Tenant.
  3. MCP Access Policies. The governance layer. Who can reach what, attached top-down and reusable across servers.

A definition is not the same thing as a running instance is not the same thing as a policy that governs it, and Obot’s UI names each of those explicitly. Once you learn the vocabulary, everything else in the admin console makes sense in half the time.

The credential model is thoughtfully split

To add my hosted MCP server to Obot, I started with the MCP Catalog → Add Catalog Entry button, which takes me to the Create Hosted Catalog Entry page. When I set up my server’s environment configuration, Obot asked for a Key (the env var name my server reads) and a Value. The Value field is a dropdown with two options: Static and User-Supplied. Static means the admin fills a fixed value at catalog-entry time and it applies to all users of the shared instance. User-Supplied means each user enters their own at connect time.

That split is exactly the two credential patterns any real governance tool needs to handle: shared service-account credentials (Static) and per-user tokens (User-Supplied). Obot exposes both cleanly, and you pick the right one at catalog creation. It’s worth knowing which you want before you start filling in the form.

The policy model is smaller than I expected, in a good way

Coming in, I’d assumed the access policy would live in some kind of domain-specific language, like YAML, with various rules, and expressions. In fact: it’s a form with two lists. WHO (users or groups) and WHAT (servers, either named individually or covered by a registry wildcard).

The simplicity is the point. A governance tool that requires you to learn a rule grammar before you can grant your first permission is a governance tool that most organizations quietly work around. Obot’s answer: pick a group, pick a set of servers, then save. It’s the kind of policy model that actually gets used. It’s coarser than a full ABAC engine (Attribute-Based Access Control), which I see as a design tradeoff most teams will happily accept in exchange for the policies being legible to non-specialists on day one. MCP servers are narrow by design; each one is a scoped adapter to a specific system. The interesting policy questions are mostly about which team can reach which adapter.

The finish line

After sorting out my MCP server catalog entry and access policies, I clicked Connect URL. Obot handed me a ready-to-use Connection URL, which I used via a shell command to let a Claude Code session know about this MCP server:

claude mcp add --transport http "<name>" "<url>"

Run that claude command and start a fresh Claude Code session. Then you can use your MCP server in Claude Code with the “/mcp” built-in command.

For my MCP server, I asked Claude to call the echo tool through the gateway. It came back with the echoed text, proving the round-trip call worked.

Then I checked the Obot Audit Logs tab. There was the row: my identity from Google OIDC, the tool name, the timestamp, the result. That’s the machinery you don’t have when every MCP is its own one-off adapter, and you can’t build it as fast as adopting an open gateway that already has it.

A naming tip

One feature that tripped me up was the use of an Obot server alias. If you are following along in Obot: the Create Catalog Entry (Hosted) form has an optional Server Alias field alongside the Name. If you fill it in, that alias becomes the primary short-name shown in deployment tables and the Access Policy picker, while the catalog entry Name still shows in breadcrumbs and post-attach policy lists. Same server, two labels. Just a UX subtlety around an optional field. If you set an Alias, note what you put there. Six weeks later you’ll thank yourself.

Beyond that: I’d say run a verify pass before you trust your setup. The end-to-end path involves enough moving parts, such as: Google OIDC, catalog entry, deployment, access policy, connection URL, client config.

It’s not hard for a first-time user to miss subtle details that are needed for success. Repeat the flow on a fresh server before you conclude anything is broken or push to production. That’s good practice for any governance tool you’re adopting. The second pass is where I found my own mistakes were the source of what looked like platform issues.

Why I’d recommend Obot to a team hitting the MCP-sprawl wall

Three reasons, from the practitioner side:

  • The gateway pattern is exactly what MCP-at-scale needs. Every team building custom MCPs is going to hit the sprawl problem eventually, and doing the ops-and-security work fresh for each server is time you don’t have.
  • The team behind Obot built Rancher into the Kubernetes management leader. The same product pattern reads on this codebase: open source, credible governance, and a real enterprise story. That’s not a small credential.
  • The product is great for a team learning to deploy MCP servers. Obot exposes a simple, legible policy model instead of a complex one; it gives you a full 3-part lifecycle instead of hiding the moving parts behind a single overloaded form; it ships with a substantial pre-installed catalog and useful defaults. It’s what a governance tool for MCP should look like at this stage of the market.

If your team has Claude, or some other LLM, reaching into systems and no gateway in front of it yet, Obot is worth a try. It’s what I use when a client engagement calls for MCP governance done right.

This is what I do for a living: build the small, sharp AI tools that run in a real business, and put the governance in so the people who own the risk can sleep. If you’ve got Claude reaching into systems and no gateway in front of it yet, that’s a conversation I’d love to have: atelier.purpleblossom.ai. Comments on this article or the work are welcome too; I’m all about connecting, learning, and listening.

The product side of my company builds Blossom Grove, a sales tool for small businesses. The MCP server I put behind Obot in this post is how we let LLMs reach Blossom Grove; purpleblossom.ai has the product story.

And if you want to try the gateway: Obot is open source. obot.ai.