Skip to main content

​
What a Connector Is

A connector is a managed MCP server in Runlayer. It packages the MCP endpoint together with auth, configuration, permissions, and client setup instructions so your team can use it from any AI client. Key parts:
  • Tools: Actions the MCP can perform (e.g., “create issue”, “search code”)
  • Resources: Data the MCP can access (e.g., repository files, issues)
  • Status:
    • Active — Ready to use
    • Disabled — Turned off or not yet configured
    • Draft — Only visible to the creator; hidden from other users, the MCP endpoint, and the proxy until the connector is activated
    Connector requests (when a team member asks an admin to add a connector) have their own statuses: Pending, Approved, and Rejected.
There are three ways to add connectors to Runlayer: from the connector catalog, manually, or via Runlayer Deploy.

​
The Connector Catalog

The connector catalog is Runlayer’s curated registry of pre-validated MCP server templates. When you open Connectors, the catalog is what powers the list of connectors your team can browse and request.
Connectors is the item in the left sidebar. The page it opens lists the connectors a policy grants you and is titled My connectors (with the new navigation, My connectors is the first tab, and admins also get an All connectors tab).

​
What you get from catalog connectors

  • Validated to work — Runlayer has tested each catalog connector to confirm it works correctly
  • ToolGuard security scans — Each connector’s tools have been statically scanned for security risks. You can review scan results before enabling a connector.
  • Pre-filled configuration — Selecting a catalog connector pre-fills the setup form with the correct transport type, auth method, environment variables, and defaults. No guesswork.

​
How it works

Catalog entries are templates — they don’t become connectors until someone adds or requests them. For admins:
  1. Open Connectors in the left sidebar
  2. Use search or the All / Hosted / Local tabs to find a connector
  3. Open any connector card to review its tools, description, and security scan results
  4. Click Add connector to create a connector from the template
  5. Complete any remaining setup (auth, environment variables) and save
For team members:
  1. Browse Connectors the same way
  2. Click Request new on the connector they need
  3. Enter a reason for the request
  4. An admin reviews and approves or rejects the request
Admins manage requests from the Manage connectors view.

​
What happens after a request

  1. Pending — The request appears with Pending status. You can see your own pending requests on Connectors. Admins are notified by email and, if configured, in a Slack channel.
  2. Approved — The admin sets up the connector (auth, configuration) as part of approving. The request status changes to Approved, you’re notified via Slack DM, and the connector becomes available to connect from your AI clients. No further action is needed beyond connecting it in your client.
  3. Rejected — The request status changes to Rejected and you’re notified via Slack DM, including the rejection reason if the admin provided one. Talk to your admin if you believe the connector should be reconsidered.
Every decision is recorded in the audit log. See Approvals for the admin side of this workflow.

​
External approval forms

Workspace admins choose where new connector requests go under Settings → General → New connector requests. Turn the toggle on, then pick one option under Where requests go: With the toggle off, employees can’t request new connectors. Saving with the toggle off or with Runlayer selected removes the approval form link and instructions. Your approval form and Both require an Approval form link (an HTTPS link of up to 2,000 characters, with no username or password) and Instructions (plain text, up to 2,000 characters) telling employees they’ll be taken to your organization’s approval form. Under Employees see, the settings page previews the instructions and button exactly as employees see them. The Open approval form button has an external-link icon. Hover over it or focus it with the keyboard to see a tooltip naming the destination host and explaining that it opens in a new tab. Submitting through the external form follows your organization’s approval process. Opening the link creates no pending Runlayer request or approval notification. Runlayer does not track the external form’s status; approved connectors still need to be added by an authorized admin or API principal. Requests for access to existing connectors retain their separate workflow.

​
Full catalog list

The catalog is continuously growing. To request the full list of available connectors, ask your account representative. A snapshot of what’s covered today:
  • Built and maintained by Runlayer — connectors with dedicated setup guides: Adaptive, Gong, Google Workspace, Metabase, Microsoft 365 (Outlook, OneDrive, SharePoint, Calendar, Teams), Slack, and Snowflake
  • Official vendor MCPs — servers maintained by the upstream SaaS provider (e.g., GitHub, Asana, Ramp, Datadog, Microsoft Agent 365), many connected through the OAuth Broker
  • New connectors ship regularly — see the changelog for recent additions
Runlayer doesn’t limit you to the catalog: any MCP server can be added manually.

​
Runlayer-built vs. vendor-native vs. custom

Connector pages and catalog entries can represent several ownership models: Vendor-native connectors inside Claude, ChatGPT, or another client can coexist with Runlayer, but Runlayer can only enforce policies, ToolGuard, and audit logs on traffic that goes through Runlayer or a supported endpoint hook. On managed devices, the AI Watch endpoint mode decides whether they keep running; see what coexist means.

​
Catalog connector types

Some hosted connectors are Runlayer-managed — Runlayer hosts and runs the MCP server infrastructure for you. For details on local execution, proxying, setup, and local secrets, see Local MCPs.

​
Adding a Connector Manually

If the MCP server you need isn’t in the catalog, admins can add it directly using the Create New button. This bypasses the catalog entirely and lets you point Runlayer at any MCP endpoint.

​
When to use this

  • Internal or proprietary MCP servers — Built by your team for internal use
  • Community or unofficial MCP servers — The catalog only includes servers officially maintained by the upstream SaaS provider. Community-built or third-party servers should be added manually.
  • Existing MCP endpoints — You already have an MCP server running and want to manage it through Runlayer
If your manually added connector requires IP allowlisting, open Settings → Network Access and allowlist the tenant-specific outbound IPv4 addresses and IPv6 ranges shown there. For an MCP server on a private network (VPC, Kubernetes cluster, or behind a VPN), use a tunnel instead.
Does Runlayer need direct access to my private apps? Only for HTTP-based connectors whose upstream MCP endpoint is private. You have two options: allowlist Runlayer’s outbound IPs (shown in Settings → Network Access) in your firewall, or run a tunnel connector inside your network so nothing has to be opened inbound. Local MCPs run on the user’s machine behind the Runlayer CLI, so Runlayer doesn’t need inbound network access to the user’s machine or the systems the local MCP reaches.

​
How to add a connector manually

1

Open the Add Connector dialog

From Connectors or Manage connectors, click Add connector, then click Create New to skip the catalog and go straight to the configuration form.
2

Configure the basics

Fill in the required fields:
  • Icon — Pick a custom icon for the connector (optional; only for custom connectors — catalog connectors use their predefined icon)
  • Name — Display name for the connector
  • URL or Command — The MCP endpoint URL (e.g., https://mcp.example.com/mcp) or a command for STDIO servers. For hosted STDIO, use npx, uvx, or uv; for local STDIO, any local binary command is allowed.
  • Transport type — Streaming HTTP (default), SSE, or STDIO
3

Set up authentication

For HTTP-based transports, choose an auth method:
  • Auto — Runlayer auto-detects the auth mechanism (default)
  • OAuth 2.1 — Configure OAuth with Client ID Metadata Document or Dynamic Client Registration, pre-registered credentials, or the OAuth Broker
  • Bearer Token — Static token-based auth
  • None — No authentication required
For STDIO transports, configure arguments and environment variables instead.
4

Configure advanced settings (optional)

Expand Advanced settings to configure:
  • Description — What the connector does
  • Tool output offloading — Prevents context bloat from large tool outputs (enabled by default)
  • Skip tool input validation — Bypass strict MCP input schema validation for servers with malformed schemas; disables server-scoped payload-based PBAC conditions
  • Sensitive Connector (Super Admins only) — Redacts tool call payloads from this connector’s audit log entries for everyone without a selected viewer role. Not applied to the SIEM export. See Sensitive Connector Redaction
  • Identity Forward — Inject the authenticated caller’s identity into upstream requests via plain headers or a signed JWT. See Deploy — Identity Forward for the full reference. Available on any HTTP-based connector (Streaming HTTP or SSE), not just deployed servers.
5

Save

Click Create to add the connector. It’s now available in your workspace and can be assigned to users, have policies applied, and be connected to AI clients.
Headers for HTTP connectors support placeholder syntax (e.g., {"{API_KEY}"}) so each user can provide their own credentials at connection time. Local HTTP/SSE connectors are an exception — they require literal header values; see Local MCPs.

​
Private MCP servers reached through a tunnel

Use a tunnel when the MCP server lives on a private network that Runlayer can’t reach over the internet, for example a Kubernetes cluster in your VPC or a host behind a VPN. You run a small tunnel connector container next to the server. It opens an outbound HTTPS connection to Runlayer and forwards Runlayer’s requests to the server. Nothing needs to be opened inbound, and Runlayer doesn’t need to see or discover your cluster: it only reaches the addresses you map. There are two pieces: a tunnel connection (the network path, created in Settings → Network Access) and the connector that uses it (the MCP server itself, created in Connectors).
Tunnels must be enabled for your workspace. If Settings → Network Access has no Private network connections section or no Add connection button, ask your Runlayer contact to turn tunnels on.
1

Create the tunnel connection

As an admin, open Settings → Network Access and click Add connection. If it asks for a Connection type, pick Tunnel. Enter:
  • Name: lowercase letters and numbers separated by single hyphens, for example internal-mcps. You’ll pick it by this name on the connector.
  • Ports: the TCP ports Runlayer may use through the tunnel, comma separated, for example 8000, 8001. Use one port per MCP server unless they share a reverse proxy. Ports 65534 and 65535 are reserved.
2

Copy the token and run the connector

The Tunnel connection created dialog shows a connector token and a docker run command. The token is shown only once; copy it now. If you lose it, use Rotate token on the connection.Before running the command, replace each CHANGE-ME.internal in RUNLAYER_TUNNEL_MAP with the address the connector should forward that port to, as seen from where the connector runs:
The left side of each entry is a tunnel port; the right side is the real host and port. No http:// or path goes in the map. Run the connector anywhere that can reach those addresses: a host, a separate Deployment next to the MCP Service, or a sidecar in the MCP server’s Pod. For a managed deployment, mount the token as a secret file and set RUNLAYER_TUNNEL_TOKEN_FILE instead of RUNLAYER_TUNNEL_TOKEN.The command is written for bash (Linux, macOS, WSL). In PowerShell, replace each trailing \ with a backtick (`), or put the whole command on one line.Wait until the connection shows Connected in Network Access.
3

Add the connector

Add the MCP server manually, and under Show advanced settings pick the tunnel in Private connection. For URL, enter the server’s own private URL using a tunnel port, for example http://jira-mcp.internal:8000/mcp, not a Runlayer URL. Set up authentication as you normally would: the tunnel only carries the traffic, it doesn’t replace the server’s own auth.
The rest of this section covers URL rules, network requirements, and how many connectors to run. For a connector attached to a Runlayer tunnel, use a fixed MCP hostname such as https://github.private.example/mcp. Hostname placeholders such as https://{tenant}.private.example/mcp and wildcard hosts are not supported. Placeholders in URL paths, query strings, headers, and OAuth configuration remain supported. An organization can attach only one MCP connector per hostname across all its tunnel connections. Different paths, ports, or HTTP/HTTPS schemes do not make the hostname available for another connector. For example, https://private.example/github/mcp conflicts with both https://private.example/jira/mcp and https://private.example:8443/jira/mcp, even on separate tunnels. Disabled connectors keep their hostname reserved; deleting the connector or removing its tunnel attachment releases it. For multiple services behind a reverse proxy, configure a distinct fixed hostname for each and have the proxy route each hostname to its intended service. The customer service must still enforce authentication and authorization. The tunnel does not inspect HTTP paths or detect different hostnames pointing to the same service; URL paths are not a tunnel authorization boundary. For OAuth, the authorization server must either be publicly reachable or share the MCP server’s hostname, scheme, and port. Only requests to the connector’s own hostname travel through the tunnel; an authorization server on a different private hostname is reached over the public internet and OAuth discovery fails. Removing a tunnel attachment through an update runs the connection test against the current URL over the public internet, so detaching a connector whose URL is only reachable privately fails. To stop using the tunnel, delete the connector or change the URL in the same update.

​
Network requirements for the tunnel connector

The tunnel connector only makes outbound connections. Open no inbound ports. Allowlist the Runlayer host by hostname. A Runlayer-hosted tenant hostname points to an AWS load balancer whose IP addresses change, so there is no fixed IP range for connector egress. The outbound IPs under Settings → Network Access are the source addresses Runlayer uses to reach services over the public internet. Tunnel traffic doesn’t use them, so you don’t need them to lock down the connector. If the connector must go through an egress proxy, set HTTPS_PROXY on it to an http:// or socks5:// proxy.

​
How many connectors to run

  • One tunnel connection can serve several MCP servers. Give each server its own exposed port in Ports and map it in RUNLAYER_TUNNEL_MAP, for example 8000=jira-mcp.internal:8000,8001=github-mcp.internal:8000. Servers behind one reverse proxy can share a port if each uses its own hostname, as described above.
  • Extra connectors on the same connection are for availability. Every connector uses the same token and fingerprint and maps every exposed port. Each one can point at its own replica. Runlayer spreads new TCP connections across the healthy connectors. By default a connection accepts up to 32 connector sessions, counting old and new connectors that overlap during a rollout.
  • Run exactly one connector for an MCP server that keeps session state in memory. The tunnel doesn’t pin an MCP session to one replica, so a second connector could send a session’s requests to a server that doesn’t know it.
  • Use separate tunnel connections for MCP servers in different networks, or when you want to rotate tokens independently. Rotating a connection’s token interrupts every MCP server attached to it.
On Kubernetes, the connector can run as a sidecar next to each MCP server Pod, or as its own Deployment that targets the MCP server’s Service. Ask your Runlayer contact for example manifests.

​
Deploying a Custom Connector

For MCP servers you build yourself, Runlayer Deploy lets you deploy them to managed infrastructure. Start the process from Connectors, then use the CLI to deploy the server.

​
When to use this

  • You’re building a custom MCP server for your team
  • You need managed infrastructure (auto-scaling, HTTPS, monitoring)
  • You want the full lifecycle: build, deploy, and manage

​
How it works

1

Create the connector

Open Connectors. Select Add Connector → Deploy an MCP server on Runlayer → Create from manifest.Enter the connector details. Runlayer creates the connector with Draft status and opens its Manifest tab.
2

Pull the manifest

Copy the deployment ID from the connector’s Manifest tab. The pull command creates a local runlayer.yaml file.
3

Configure and deploy

Edit runlayer.yaml with your service port, resources, and environment variables, then deploy:
Runlayer builds your Docker image, pushes it, and deploys it to managed infrastructure.
4

Activate the connector

After the first deployment succeeds, Runlayer changes the same connector from Draft to Active. No separate publish or registration step is required.
While the connector is in Draft, only its creator can see it. Users cannot connect to it until the first deployment succeeds.
For the full configuration reference, CLI commands, and examples, see the Deploy documentation.

​
Will an arbitrary MCP server work?

Any MCP server can be added manually, but “can be added” and “works end-to-end today” are not the same thing. A catalog entry is Runlayer’s signal that we have tested that server end-to-end and confirmed it works through the gateway. Servers you add yourself have not been through that validation, so a small number hit one of the issues below before they connect cleanly. When you’re scoping a POC, inventory the MCP servers your team already uses in Claude, ChatGPT, and Cursor early — a few of them can take days or weeks to clear, and you want that clock started before the POC, not during it.

​
Three things that decide whether a server connects

Some servers deviate from the MCP specification. Like other MCP clients (Claude, ChatGPT, Cursor), Runlayer tolerates common deviations, and the manual Create New setup form exposes options to work around them — for example, adjusting transport type or auth handling — so you rarely need the vendor to change their code. If a server fails to connect and you suspect a spec quirk, contact your Runlayer account team; we can usually add a compatibility option.
Many hosted MCP servers only accept connections from a short list of named clients (commonly Claude, ChatGPT, and Cursor) and reject everything else. When the server you want does this, the vendor has to allowlist Runlayer as an approved MCP client before it will connect. Runlayer handles this outreach, but it depends on the vendor’s timeline — most agree quickly, some take longer.A related case: a few servers have no publicly connectable MCP endpoint at all. For those, Runlayer can build and host an equivalent server on Runlayer Deploy.
Because vendor allowlisting is outside Runlayer’s control, treat any un-cataloged, client-restricted server as a potential multi-week item and raise it before the POC starts.
Most servers fall here. Occasionally there’s one-time admin setup on the vendor side — flipping a “allow all MCP clients” setting, or pasting Runlayer’s OAuth redirect URIs into the vendor’s app registration. When a Runlayer-built or catalog connector needs this, the setup guide links the exact place to do it.

​
Not in the catalog yet?

Missing from the catalog is not a blocker on its own. You can:
  • Add it as a custom connector now with Create New and point Runlayer at the endpoint. If the server is client-restricted (case 2 above), ask your account team to start vendor allowlisting in parallel.
  • Request catalog coverage so Runlayer validates it end-to-end and pre-fills its configuration for everyone — ask your account representative.
Custom and catalog connectors are governed identically once connected: the same policies, ToolGuard scanning, and audit logging apply regardless of how the connector was added.

​
Inventory your servers first

Before you roll out, list the MCP servers your team already uses in Claude, ChatGPT, and Cursor, then classify each one: Doing this up front keeps any vendor-side items visible from the start.

​
Using connectors in an AI client

Open a connector and click Add to Client. If the connector is already included in Runlayer Plugin, Runlayer recommends that shared connection first. Click Connect to use Runlayer Plugin, or continue with the client-specific instructions to add the connector directly. To work with several connectors at once:
  1. Open Connectors and select the connector cards.
  2. Click Add to Client in the selection bar.
  3. Use Runlayer Plugin, add the connectors to an editable Plugin, or create a new Plugin.
Only active hosted connectors can be selected for a Plugin. Local, draft, and disabled connectors still use their existing setup paths. See Plugins for the complete flow.

​
Authorizing at use time

Adding a connector to a client and authorizing your account with the upstream provider are two separate steps, and they don’t have to happen together. Connectors can reach a client before anyone has authorized anything — added by the user, included in a Plugin, or pushed by auto-provisioning — and each user authorizes afterwards rather than as a prerequisite. This is the recommended rollout: install the Runlayer endpoint in the client once, and let each user authorize only the connectors they actually reach. Users don’t need to visit the Runlayer app first. How long authorization can be deferred depends on the client: In-chat authorization surfaces one of two ways, depending on whether Runlayer already knows the connector’s tool list:
  • Tool list not yet known — the connector exposes a single placeholder tool, AUTH_REQUIRED_<connector>. Calling it returns the authorization link.
  • Tool list already known (cached, or a catalog connector) — the real tools list normally, and the authorization link comes back when the user first calls one.
Either way the fix is the same: complete OAuth, then retry. The real tools replace the placeholder. For the full walkthrough, including tool-list cache caveats, see Troubleshooting → “Connector lists only an ‘Authorize’ or ‘Inputs Required’ tool”.
Use-time authorization changes when a user authorizes, not whether they have to. Each user still completes the provider’s consent screen once per OAuth connector, with their own credentials — that consent is what makes per-user attribution and revocation possible.
Super Admins control in-chat authorization from Settings → General → “Just-in-time” Connector Authentication. It’s enabled by default and covers ChatGPT, Claude, and CLI-proxied traffic; disabling it drops all three to the 401 path. Runlayer Plugin traffic always authorizes in-chat and is unaffected by the toggle.

​
Security

All connectors — regardless of how they’re added — are protected by Runlayer ToolGuard. ToolGuard is a suite of ML models that detect tool poisoning, prompt injection, and data exfiltration in real time.

​
How ToolGuard applies to each flow

Tool List Guard scans tool definitions (names, descriptions, parameters) to detect hidden instructions, prompt injection, and risky patterns before tools are made available:
  • Catalog connectors are pre-scanned by Runlayer before being published to the catalog. Scan results are visible on each connector card so you can review them before enabling.
  • Manual and deployed connectors are scanned by Tool List Guard when they’re registered. You’ll see the same scan results, but Runlayer hasn’t pre-reviewed them — it’s on the admin to review before enabling.
Tool Call Guard scans tool outputs at runtime to detect data exfiltration, prompt injection in responses, and command injection before results reach the LLM. This applies to all connectors equally, regardless of how they were added. Tool Intent Guard analyzes tool inputs and outputs together to detect semantic misalignment — cases where a tool’s behavior diverges from what was requested (e.g., a “read file” tool that silently exfiltrates data). This also applies to all connectors at runtime.
ToolGuard sensitivity can be configured globally in Settings → Security Scanners, overridden per connector, or set per client. See ToolGuard Models for details.

​
OAuth Redirect URI Controls

When a connector uses OAuth, the AI client sends the user to the provider’s login page and asks it to deliver the resulting authorization code to a redirect URI (also called a callback URL). That redirect URI is where the short-lived code — and ultimately the access token to your data — lands.

​
Why a malicious redirect URI is dangerous

A redirect URI is a high-value target. If an attacker can get a connector to redirect to a URI they control, the OAuth flow hands them the authorization code, which they exchange for a live access token — no password or MFA prompt required. Common attacks include:
  • Authorization-code interception — a look-alike or attacker-owned callback (e.g. https://app.evil.com/oauth/callback) silently captures codes mid-flow.
  • Open-redirect chaining — a trusted host with an open redirect is abused to bounce the code on to an attacker.
  • Consent phishing — users are walked through a real-looking consent screen that quietly points at the wrong destination.
Because the token grants the same access the user has, a single bad redirect URI can lead to data exfiltration that never trips a login or MFA challenge.

​
How Runlayer enforces redirect URIs

Admins control which redirect URIs OAuth clients may use under Settings → General → OAuth redirect URIs:
  • Allowed redirect URIs — trusted URIs that connect with no extra prompt.
  • Blocked redirect URIs — URIs blocked org-wide.
  • Entries support exact URIs and wildcard host patterns (e.g. https://*.example.com/cb).
Behavior at connect time:
  • A redirect URI on the allowlist proceeds normally.
  • A redirect URI on the denylist is blocked. Blocking always wins over allowing.
  • A redirect URI that matches neither list pauses the flow and asks an admin to approve it before anyone in the org can use it.
Every block and approval is recorded in the audit log.
Recipe: trust local (loopback) clients in one shot. Many CLI and local dev MCP clients receive their callback on a loopback address with a random port, per RFC 8252. To allow them without an approval prompt on every new port, add the loopback hosts with a trailing path wildcard to Allowed redirect URIs:
Loopback matches ignore the port, so each entry covers any ephemeral port the client picks. http is permitted only for these loopback hosts — never for remote hosts — so this does not weaken protection against external redirect URIs.Some clients instead use a custom-scheme deep link (a “magic link”) rather than a loopback callback — for example Cursor uses cursor://anysphere.cursor-mcp/oauth/callback. Allowlist that exact URI as-is; the loopback patterns above do not cover it.

​
What to do if a redirect URI is blocked

If you saw “This redirect URI is blocked for your organization” while connecting a client, the callback URL your AI client tried to use is on your organization’s blocked list. This is a safety control, not a bug — it stops OAuth tokens from being handed to an untrusted destination. What to do:
  1. Confirm you’re connecting an approved, official client — not a fork or a tool from an untrusted source.
  2. Share the connector and the client you’re using with your Runlayer admin.
  3. An admin can review the redirect URI under Settings → General → OAuth redirect URIs and, if it’s legitimate, add it to the allowed list.
Admins: only allow redirect URIs you recognize and trust. Adding a URI here tells Runlayer to hand OAuth tokens to that destination for everyone in your org. When in doubt, leave it blocked.

​
Comparison

Any hosted STDIO connector — whether from the catalog or created manually — automatically runs on Runlayer infrastructure. HTTP-based connectors (Streaming HTTP, SSE) connect to an upstream URL, unless you use Runlayer Deploy to host the server yourself. Local connectors are the exception: they run on the user’s machine and require the Runlayer CLI to be installed there.

​
Managing Connectors

Admins have a separate Manage connectors view for workspace-wide inventory, approvals, and permissions.
From Manage connectors, admins can:
  • View all connectors across the workspace
  • Approve or reject connector requests from users
  • Edit connector settings, including auth configuration
  • Disable or re-enable connectors
  • Apply policies to control tool access
  • Monitor connector status and usage via analytics and audit logs

​
Editing connector settings

Admins can edit an existing connector’s configuration — including authentication method, OAuth settings, headers, and environment variables — from the Settings tab on the connector’s detail page (Manage connectors → [connector] → Settings). This is the same form used when creating the connector, so anything set at creation time can be changed later. If a connector’s credentials change or expire, individual users may also need to revoke and reconnect their own authorization — see Troubleshooting: Revoke and Reconnect App Authentication.

​
Disabling and re-enabling connectors

Admins can disable any connector from its detail page (Disable server in the actions menu) or as a one-click remediation from Incidents. Disabling sets the connector’s status to Disabled, making it inaccessible workspace-wide until an admin re-enables it from the same menu. Both actions are recorded in the audit log (server_disabled / server_enabled events, including who acted and the disable reason).

​
Searching connectors

Connectors can be searched by name or description in two ways:
  • Command palette — press Cmd/Ctrl+K from anywhere in the app and type a connector name
  • API — use the query parameter on the servers API to filter connectors server-side

​
FAQ

No. A connector’s authentication method is fixed when you configure it (Auto, OAuth 2.1, Bearer Token, or None), and it authenticates exactly one of those ways. To reach the same upstream MCP server both as a user (OAuth / on-behalf-of) and as an autonomous service (a static service credential), create two connectors pointed at the same endpoint — one OAuth and one Bearer Token. This is the standard pattern for agent accounts; you scope what each agent can do with policies rather than by cloning connectors. See Agent Accounts → Connectors for agent accounts.
There’s no fixed cadence. For OAuth connectors, tokens are refreshed automatically where the vendor supports it, so users typically authorize once and stay connected until the token is revoked or the vendor’s refresh expires. Lifetimes vary by vendor — for example, Salesforce access tokens last about 2 hours but refresh automatically when the refresh_token scope is enabled. When automatic refresh isn’t possible (token expired, revoked, or scopes changed), users see auth errors like 401 Unauthorized and need to revoke and reconnect — see Troubleshooting. Many AI clients prompt for re-authentication automatically in that case.

Runlayer Plugin

Get your first connector working in a client

Deploy

Deploy custom MCP servers to managed infrastructure

Policies

Control tool access with policies