2026-07-28, a client declares the
version and its capabilities on every request (in the MCP-Protocol-Version
header and the request’s _meta), with no initialize handshake or session.
On the handshake revisions 2025-03-26, 2025-06-18, and 2025-11-25, a
client negotiates with initialize: requesting a newer handshake revision
gets the latest one, and an older or unrecognized version is served as
2025-03-26. server/discover returns every supported version, the
server’s capabilities, and its identity in one round trip. A request that
declares a stateless revision Conduit does not serve is answered with the
spec’s UnsupportedProtocolVersionError listing the supported versions, so
the client can retry with one of them.
Besides tools, Conduit serves the prompts, resources, and resource templates
your connectors expose, under the same access policies: a prompt appears as
<connector>__<prompt-name> in prompt-aware clients (slash commands, prompt
pickers), a connector’s resource appears under a
conduit://<connector>/<original-uri> URI (templates expand inside that
form), and your client is notified when your tool, prompt, or resource set
changes through Conduit — an admin’s policy or connector edit, a change to
your role, or a connection of your own — on the stateless revision, over the
subscriptions/listen stream it opens for the change types it wants. A tool a
connector adds on its own side shows up the next time your client re-lists. Subscriptions to updates of an
individual resource are not offered. Resource references inside a prompt or tool result — resource links,
embedded resources, and mentions of those same URIs in the result’s text —
are served in that form too, so a URI a connector hands your model is one the
gateway can read back; reading a URI outside the form returns an error naming
the expected shape. Argument completion (completion/complete) for a prompt
or template routes to the connector that owns it. Connectors that don’t offer
a surface simply contribute nothing to it.
Clients that opt in receive gateway log messages — on a handshake revision
by calling logging/setLevel, and on the stateless revision by setting a log
level on a request, whose messages then arrive with its response:
a warning when one of your connectors fails while its tools, prompts, or
resources are being listed (a failure that otherwise degrades silently — the
other connectors still serve), and the log messages a connector itself emits
while answering one of your requests, forwarded with a connector:<name>
logger prefix.
Tool, prompt, and resource listings are returned in a single page: Conduit
never issues pagination cursors, and a request that carries one is answered
with an invalid-params error rather than a silent restart of the list. A
client can abort a long-running request (a slow tool call, for example) with
the standard notifications/cancelled notification — on the stateless
revision, by closing the request’s connection — which also aborts the
connector call behind it. A tool call that asks for progress (a
progressToken in its _meta), from a client connected to Conduit over HTTP
that accepts a streamed response, receives the connector’s
notifications/progress reports on that call’s response as the connector
sends them, if the connector reports progress. Progress does not extend the
gateway’s time limit on a connector call.
A tool call that fails in the connector behind it — an unreachable server, an
HTTP error, a response over the gateway’s size limit, a timeout — comes back
as a tool result with isError: true whose text describes the failure, so the
model sees what went wrong and can adjust. When the gateway’s own limits are
what stopped the call, the text says so and how to work within them (request
less data, or less work per call). Protocol-level errors are reserved for
malformed requests and the gateway itself.
Standard MCP metadata also passes through the gateway: tool output schemas and
metadata, structured tool results and result metadata, and resource metadata
reach the client without connector-specific fields being discarded.
Clients that declare the MCP Apps UI extension can render interactive HTML
templates exposed by remote MCP connectors. Conduit keeps each template under
its connector’s namespace while preserving the ui:// scheme Apps hosts use,
and relays the template metadata, structured result, and result metadata the
view consumes. If a view requests the exact local template URI it was authored
with, Conduit resolves it when a single accessible app declared that URI;
conflicting declarations produce an explicit ambiguity instead of selecting an
unrelated app. For secondary local resources that were not declared in tool
metadata, Conduit checks every accessible app connector concurrently, with no
fixed connector limit, among connectors currently advertising an app template.
It accepts the content only when exactly one connector serves it and every
other connector reports a definite miss; multiple matches or an unavailable
candidate produce an explicit error rather than potentially routing the view to
the wrong app. Clients that do not declare Apps support do
not receive tools that are scoped only to an app view. An app view can call its
connector’s tools
by their original, unprefixed names when that name belongs to only one
accessible app connector; ambiguous names are not advertised and the call
response identifies the connector-qualified alternatives. These aliases are
visible only to app views, while the connector-qualified tools remain available
to the model. The Conduit CLI forwards a connected client’s Apps declaration
and app-local calls for remote connectors; local stdio connectors do not yet
expose their UI templates through the gateway.
Connection methods
Remote clients use the workspace URL on Conduit’s Home page. For clients that run local processes, the Conduit CLI also serves local connectors. The CLI setup UI and local connectors are behind a browser-level rollout flag and hidden by default. This flag controls UI visibility, not server access.What a client sees
- Tools are aggregated from every connector you have access to, prefixed
by connector name (for example
github__create_issue). Which tools you see is decided by your workspace’s access policies and your own enabled selection on the Connectors page. Until you make a selection there, a client sees Conduit’s own built-in tools only: a connector or app your workspace allows you is available to switch on, and appears in your client once you do. OAuth consent adds a client-specific ceiling on top: connector and personal-tool permissions are always included, while administrative permissions require an eligible admin to opt in. - Names are kept short, because your client adds a prefix of its own and
some clients reject a tool name past 64 characters. Conduit’s own tools are
advertised with no prefix at all (
get_session), and Pipedream app tools usepd__, with a shorter slug for the best-known apps (pd__gsheets-add-single-row). Usage and audit records show the full name. - The name you give the MCP server matters more than anything Conduit can
do, because your client spends it on every tool: registering this endpoint
as
conduitrather than something long leaves far more room for the tool name itself. searchandfetchare offered to ChatGPT only. A ChatGPT connector outside developer mode accepts a server only if it exposes those two names, so Conduit serves them the tools you have access to as searchable documents. Every other client gets the plain tool list instead, which already contains everythingsearchcould return — offered the pair as well, a capable client reads it as a sign there are tools it cannot see and wastes a step looking.- Tool lists update live: when an admin changes a policy or you enable a connector, connected clients are notified and refresh automatically. Through the CLI, that also starts or stops local connectors mid-session.
- Connectors are managed in the web UI, not by a tool. Conduit’s built-in admin tools can list and delete connectors, but creating or editing one is a UI action: those requests carry upstream credentials, which don’t belong in an LLM’s tool-call transcript.
Connecting your accounts from the client
Some connectors need a personal credential — an OAuth sign-in to the upstream service or your own API token — before their tools work for you. You don’t have to leave your AI client to find that out:- A connector whose tools are hidden until you connect shows a single
<connector>__authenticatetool instead. Calling it leads to a focused connect page (signing you in first if your browser has no session yet). The page connects the account in the workspace your client is using, shown at the top of the page, regardless of which workspace the web app has switched to. An app connector opens its connect flow right away; an OAuth connector asks for one click to authorize, and a token connector for your API key. If the link is for a workspace other than the one switched to in the web app, an app connector also waits for a click. Clients that support MCP URL elicitation get a native “open this page?” prompt; other clients get the link as text. - Calling any tool of a connector you haven’t connected yet gets the same treatment instead of a raw authentication error. This covers app tools too: calling an app’s tool without a connected account leads to the connect flow for that app.
- After you finish connecting in the browser, your client’s tool list refreshes automatically and the connector’s real tools appear. Clients that support URL elicitation are also notified the connection completed, so they can retry your original request on their own — no retry or “continue” message needed. On the stateless revision, the client’s retry of the original call returns the tool’s result once you finish connecting; if you haven’t finished yet, it gets the prompt again.
Multiple workspaces
On instances with multiple workspaces, the bare/mcp endpoint works when
you belong to exactly one workspace. Otherwise, address a workspace directly: