Bring your own MCP server

The vendor catalog covers integrations with one shared connection model per vendor — a single hosted endpoint, or a Conduit-run container. Some vendors don’t fit that shape: each customer runs their own instance, at their own URL, with its own authorization server. A self-hosted PBX, a per-tenant SaaS admin console, an internal tool a customer built — Conduit calls this a Bring Your Own (BYO) MCP server, and it works with any MCP endpoint that speaks standard OAuth discovery, catalog or not.

This guide walks through registering one, using a per-tenant phone-system MCP server as the worked example, since that shape — every customer at their own hostname, each with its own authorization server — is the clearest case for why BYO exists: there is no single endpoint a catalog entry could point at until someone adds the vendor.

Before you start

You need:

A Conduit role that can manage connections — owner or admin on your organization.
The MCP server’s endpoint URL, reachable over the public internet (Conduit’s SSRF guard rejects private/internal addresses — the endpoint has to be a real, publicly routable server, same as any catalog vendor).
If the server uses OAuth (the common case), nothing else — Conduit discovers the authorization server automatically. If it uses a static bearer token instead, have that ready.

Step 1 — Get the MCP server URL from the vendor

Every vendor’s own console differs; the shape is always “find the MCP entry point, copy its URL” — typically an Integrations or MCP page in the product’s admin area that shows an endpoint like https://your-instance.example.com/mcp. Use it exactly as displayed.

The server has to be publicly reachable over HTTPS (a requirement of the vendor’s own MCP feature, not a Conduit-specific one), and you need an account on it willing to authorize the connection — the tools Conduit can use are limited to whatever that account’s role already permits, the same as if that user were working in the product directly.

Step 2 — Register the server in Conduit

In Conduit, open Connections → BYO MCP servers (/connect/byo). The sidebar item is there whenever BYO is enabled for the deployment.
Fill in:
- Name — something identifying, especially if you’ll connect more than one (an MSP managing several clients’ instances might register Acme PBX, Beta LLC PBX, one per tenant; each is a fully separate connection).
- Endpoint URL — the URL from Step 1.
- Authorization header — leave blank for OAuth (most modern MCP servers). Only fill this in for a server that authenticates with a static bearer token instead of OAuth.
Click Add MCP server.

Step 3 — Authenticate

Click Connect via OAuth on the server’s card.
Conduit discovers the server’s authorization server automatically — the same discovery mechanism Claude Code’s own built-in remote-MCP support uses (RFC 9728 protected-resource metadata, then RFC 8414 authorization-server metadata) — and opens the vendor’s consent page in your browser.
Sign in and approve the request — the same “review the requested access and select Allow” screen you’d see connecting Claude Desktop or Claude Code to that server directly.
Conduit persists the tokens and returns you to BYO MCP servers, where the server’s card now shows OAuth connected. Conduit refreshes the token on its own from here on; you only need to reconnect if the vendor revokes the grant.

Step 4 — Review tools and permission tiers

Click Tools & tiers on the server’s card to see every tool Conduit discovered, each with an automatically-assigned tier:

read — tools Conduit’s classifier recognized as observation-only, from the tool’s name (list_*, get_*, search_*, and similar).
write — anything else. The classifier is deliberately conservative: an unrecognized verb is never assumed to be safe, so it defaults to write rather than read.
admin — tools touching credentials, secrets, or org/tenant/permission-level settings.

You can pin any tool to a different tier from this list; a pin overrides the auto-classification until you clear it.

The tier decides who in your organization can call the tool. BYO servers don’t use the catalog’s per-vendor access grants — access follows the caller’s organization role:

Organization role	Can call BYO tools classified…
owner, admin	read, write, and admin
member (and billing)	read only

A tool a member can’t call is also hidden from their AI client’s tool list, so what they see is what they can use. To let members reach a specific write tool, pin it to read; to keep a tool away from everyone but owners and admins, pin it to write or admin.

Most vendors publish their own read-only versus write-or-delete grouping (a phone system, for example: listing users, calls and queues versus dropping calls or changing routing). Their usual guidance is to keep the write/delete tools gated unless you’ve reviewed the workflow — in Conduit terms, leave those at write or admin rather than downgrading them, which keeps them owner/admin-only.

Step 5 — Use it from your AI client

Nothing to configure on the client side. Any MCP client already pointed at Conduit’s unified endpoint (see Connecting an AI client) picks the server’s tools up on its next tool refresh — restart or reconnect the client if it caches the list.

BYO tools are namespaced like catalog tools, byo-<server id>__<tool name>, and each tool’s description starts with the Name you gave the server, so an assistant can tell one client’s PBX from another’s:

byo-V1StGXR8_Z5jdHi6B-myT__GetUsers    [Acme PBX] Returns the PBX's users…

Ask a read-only question first — for a phone system, something like “how many extensions does the Acme PBX have?” — and check the call appears in your audit log under the server’s tool name.

Verify it worked

On the server’s card, confirm the badge reads OAuth connected (or that the Authorization header you set is correct, for a non-OAuth server).
Click Tools & tiers and confirm a non-empty tool list loads, with tiers assigned per Step 4 above. A populated list means Conduit reached the server, authenticated, and ran tools/list against it.
From a connected AI client, ask a read-only question the server can answer. A real answer means the call was routed through Conduit end-to-end; it’s recorded in your audit log.

An empty list or a load error means the connection isn’t healthy yet — see Troubleshooting below.

Troubleshooting

Symptom	Likely cause
“Add MCP server” fails immediately	The endpoint URL isn’t publicly reachable, or resolves to a private/internal address (Conduit’s SSRF guard rejects it before saving).
“Connect via OAuth” fails before the vendor’s consent page loads	The MCP servers page names the reason. `discovery` means the server did not advertise OAuth metadata (`/.well-known/oauth-protected-resource`, then `/.well-known/oauth-authorization-server`), or that metadata has no `issuer`. `registration` means dynamic client registration failed. `endpoint_rejected` means the URL is not a public https address. Conduit still refuses metadata that omits `issuer` — that check is unchanged.
Consent page loads, but the callback comes back as an error	The page names the reason. `missing_iss` means the authorization server omitted the RFC 9207 `iss` parameter after consent; Conduit refuses the connection instead of skipping that check. `issuer_mismatch` means `iss` did not match the discovered issuer. `token_exchange` means the code exchange was rejected. Reconnecting does not fix an authorization server that never sends `iss`.
Tools list is empty after connecting	The authenticated account has no permitted tools on the vendor side (check that account’s role and rights in the product), or the server’s `tools/list` call failed — check that the server is still reachable.
A tool shows under Tools & tiers but not in your AI client	Your organization role doesn’t reach the tool’s tier (members see read tools only — see Step 4). An owner or admin can pin the tool to read, or call it themselves.
Calls fail asking you to reconnect the server	The OAuth session expired and Conduit couldn’t refresh it — the vendor revoked the grant, or the server was connected before Conduit kept refresh credentials. Click Reconnect on the server’s card.
Calls fail with `BYO server "<name>": …`	The server answered, but not usefully — the message names the failing step (an HTTP status, a refused redirect, a non-JSON body). Check the server’s own logs; Conduit forwards exactly what it got back.

Frequently asked questions

Can I connect more than one instance of the same vendor?

Yes — each BYO registration is independent, distinguished by the Name you give it. This is the normal shape for an MSP: one named connection per client’s PBX, SaaS instance, or internal tool, each with its own endpoint, its own OAuth grant, and its own tool-tier pins.

Does a BYO MCP server show up in the vendor catalog?

No. BYO servers are personal-to-your-org registrations at /connect/byo, separate from the catalog at /org/catalog. They don’t appear in /docs/reference/supported-vendors/ for the same reason no other org’s BYO servers do — they aren’t a shared, generally-available integration.

What if the vendor’s MCP server doesn’t support OAuth?

Use the Authorization header field when registering the server (Step 2) instead of leaving it blank — paste a static bearer token or API key as the vendor’s docs specify. Conduit sends it as-is on every call; there’s no automatic refresh, so you’ll need to update it manually if the vendor rotates it.

Vendor connections — the catalog and its BYOC (bring-your-own-client) OAuth vendors — a different feature from BYO MCP servers.
Connecting an AI client — point any MCP client at the unified endpoint to reach every connected catalog vendor and BYO server.
Security — how Conduit encrypts and resolves stored credentials, including BYO OAuth tokens.