Connectors and Virtual MCPs

A connector is a single upstream MCP server that BridgeMCP connects to. A Virtual MCP is a named bundle of connectors exposed as one endpoint. Together they let you compose the exact tool surface each client or agent should see.

Transport types

The connector’s transport type determines how the gateway talks to the upstream server.

Remote connectors (Streamable HTTP / legacy SSE)

Remote connectors point at a vendor’s own hosted MCP endpoint. Choose http for a current Streamable HTTP endpoint. Keep sse only when an existing upstream still exposes the deprecated HTTP+SSE transport. Provide the URL and any headers the upstream server needs (including an Authorization header for token auth). BridgeMCP makes an outbound call to that endpoint and aggregates its tools.

Local connectors (stdio)

Stdio connectors run a local MCP package. The runner describes what to launch:

• npx -y <package> <args> for Node packages.
• uvx <package> <args> for Python packages.

The package and each argument are passed to the runner as separate values, never through a shell.

Package policy

You can run any public npx or uvx package, unless the BridgeMCP platform has added it to its package blocklist. Scoped names and version or tag pins are accepted, for example @scope/[email protected] or pkg@latest for npx, and pkg==1.2.3 or [email protected] for uvx.

The package name is checked when you create or update the connector. It is rejected, with a message naming the problem, if it contains whitespace or shell characters, starts with -, or is a URL, a file path, a GitHub user/repo shorthand, or a git+, file: or npm: specifier. uvx extras such as pkg[extra] are not supported.

The blocklist is checked when you create or update a connector and every time BridgeMCP starts it. A blocklist entry matches regardless of case and of any version or tag you pin, so [email protected] is blocked by an entry for some-package. An entry can be narrowed to a version range, in which case it blocks an exact pinned release in that range ([email protected] for npx, pkg==1.2.3 for uvx). It also blocks any request that does not name one exact release, such as an unpinned package, a tag like @latest, a partial or wildcard version like @1.2 or @1.x, a ^ or ~ range, or a prerelease, because the version that would be installed is unknown. Pin an exact release outside the range to use the package.

Blocked and platform-disabled connectors

A connector can show one of two platform states in the console:

• Package blocked: its package was added to the platform blocklist after you created it. It cannot be started, and a running copy is stopped. Change the connector to a different package or version, or contact support.
• Disabled by platform: BridgeMCP disabled this connector. It cannot be started, and enabling it in the console does not lift the restriction. Contact support to have it reviewed.

In both states the connector contributes no tools, and a tool call or connection test returns an error that names the restriction.

Sandbox limits

Each custom stdio connector runs in its own isolated container:

• It has no access to private or internal networks. It can reach the public internet, but not private, link-local or loopback addresses, or other connectors’ containers.
• It runs with a per-container resource limit, by default 512 MiB of memory and half a CPU.
• Your organization can run a limited number of stdio connectors at the same time on each BridgeMCP server. Starting one more fails with “Your organization is running the maximum of N stdio connectors on this server. Disable or remove an unused stdio connector, or wait for idle connectors to be released, then retry.”
• Each BridgeMCP server also has shared capacity for stdio connectors and agent workspaces. When it is used up, starting a connector fails with an error saying the server is at capacity, followed by what to do. Idle connectors are released automatically, so retrying later can succeed.

Some providers ship as built-in connectors: instead of running an untrusted third-party package, BridgeMCP runs a first-party, in-process implementation of the provider’s tools. Built-in connectors are marked as such in the connector catalog.

Virtual MCPs

A Virtual MCP groups connectors so an AI client can reach all of their tools through a single endpoint.

• Composable: combine connectors from different sources into one bundle.
• Scopable: create separate Virtual MCPs per team, environment, or use case.
• Prioritized: when connectors expose tools that could collide, connector priority within the Virtual MCP determines ordering.

A typical setup might bundle a github, jira, and sumologic connector into a dev Virtual MCP, while an oncall Virtual MCP bundles pagerduty and sumologic.

Adding a connector

1. In the console, open Connectors and choose New.
2. Pick a built-in provider from the catalog, or configure a custom connector with a transport-specific form.
3. For remote connectors, supply the URL and headers. For local connectors, choose an npx or uvx runner and any environment variables.
4. Save. BridgeMCP connects to the server and discovers its tools.
5. Add the connector to one or more Virtual MCPs.

For a custom local connector you can also paste the JSON config that the server’s README publishes for MCP clients. Choose Paste MCP config to open the paste dialog, which shows a formatted example you can copy and adapt. Paste either the full {"mcpServers": {...}} block, a single named entry such as {"my-server": {"command": "npx", "args": [...], "env": {...}}}, or a bare {"command": ..., "args": [...], "env": {...}} object, then choose Apply config. The dialog closes and the form fills in the runner, package, arguments, and environment variables, plus the name when the paste includes one. Nothing is saved until you review the fields and create the connector, and the connector is checked exactly as if you had typed it in. Each paste creates one connector, so a block listing several servers is rejected. Only npx and uvx servers can be pasted; configure a remote server that has a url with the HTTP transport instead. In the arguments field, wrap an argument that contains spaces in double quotes.

Next steps

• MCP endpoints explains tool namespacing and routing.
• Custom HTTP tools gives one agent tools backed by your own HTTP endpoints. They are not connectors and are not exposed through Virtual MCPs. To give MCP clients access to your own API, run an MCP server for it and add it as a connector.
• Authentication and security describes outbound OAuth for connectors.