Connect clients

You have a running backplane. This section wires operators and agents to it — the CLI first, then the MCP client matrix, then a symptom-first troubleshooting page for the auth walls every first connection tends to hit.

MEHO is internal-only — never publicly exposed

MEHO is a governance backplane for internal infrastructure. It is deployed VPN-internal / behind an internal CA by design and must never be placed on public DNS or a public ingress — not even a short-lived copy. Every client below connects from a machine already on the internal network / VPN. This rules out the cloud-brokered remote Custom Connector (see below); do not expose the backplane to make it work.

Start with the CLI

Even if your end goal is an agent in Claude Desktop or Claude Code, install and log in with the meho CLI first. Two reasons:

• Registering targets and secrets has no MCP tools — deliberately. That is an operator-trust decision, so it lives on the CLI, the operator console, and REST; agents get the read-only list_targets tool and consume whatever you registered (Register targets and secrets). Until at least one target exists, an agent session can discover operations but cannot act — so the CLI is a prerequisite for a useful agent session anyway.
• The CLI is the fastest way to prove the realm, TLS trust, and token chain are correct before you add an MCP client's moving parts on top.

The fastest path: one-command onramps

For the two Claude clients, you do not have to hand-write any MCP config. Each has a one-step onramp that wires everything for you:

• Claude Code — a plugin from an in-repo marketplace: claude plugin marketplace add evoila/meho, then /plugin install meho@meho. See Claude Code.
• Claude Desktop — a one-click .mcpb bundle: install by opening the file and answering a short dialog. See Claude Desktop.

Both onramps still connect from your VPN-connected machine and expose nothing to the internet. The manual recipes below remain the fallback, and the path for every other client. Whichever you pick, an agent session lists a small, tiered set of meta-tools — see MCP surface and scopes.

The MCP client matrix

All three MCP paths are internal-only — the client, or the local shim it spawns, runs on a VPN-connected machine and speaks Streamable HTTP to the backplane's /mcp route directly. Pick the row that matches your client:

Client	How it connects	Page
Claude Desktop	One-click .mcpb bundle (recommended), or a manual local mcp-remote stdio→HTTP shim running the OAuth 2.1 + PKCE flow and forwarding to /mcp. The shim is the only Desktop transport for an internal-only backplane.	Claude Desktop
Claude Code	One-command MEHO plugin (recommended), or a manual native-HTTP .mcp.json with a loopback PKCE flow pinned to the pre-registered meho-mcp public client. The pattern both dogfood repos run daily.	Claude Code
Cursor and other clients that can't carry a client_id	A generic mcp-remote stdio shim carrying a CLI-minted bearer token.	Other MCP clients

All three assume the realm already has the public meho-mcp OAuth client and the operator's workstation trusts the deployment's CA. The one-time realm work is in Keycloak realm setup; the CA-trust step is in TLS and ingress.

Remote Custom Connector — not applicable

The remote claude.ai / Claude Desktop Custom Connector (pasting a /mcp URL into Settings → Connectors) is not a supported path for MEHO. Its connector backend runs in Anthropic's cloud, so it requires the backplane to be publicly reachable to fetch the RFC 9728 metadata and run the OAuth handshake — a requirement MEHO, being internal-only, deliberately never meets. Reach Claude Desktop through the mcp-remote shim instead, which runs on your own VPN-connected machine and exposes nothing.

When something breaks

First connections fail in a small, well-mapped set of ways — a token that decodes but is rejected, an empty tool list, a client that never reaches the OAuth screen. The troubleshooting page is symptom-first: find your error message, read the wall behind it, fix it.