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 My connectors, the catalog is what powers the list of connectors your team can browse and request.

​
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 My 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 My 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.

​
Full catalog list

The catalog is continuously growing. To request the full list of available connectors, ask your account representative.

​
Catalog connector types

TypeDescriptionExamples
HostedConnects to external cloud services via APISlack, GitHub, Salesforce, Google Workspace
LocalOperates on the user’s local machine or filesystemFilesystem, shell, local databases
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 other special networking requirements, such as VPN or private subnets, contact Runlayer to configure connectivity.

​
How to add a connector manually

1

Open the Add Connector dialog

From My 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:
  • 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 (e.g., npx)
  • 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 Dynamic Client Registration (or Client ID Metadata Document when CIMD is enabled in Settings), 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 — Redacts audit log entries and restricts visibility to selected roles
  • 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.

​
Deploying a Custom Connector

For MCP servers you build yourself, Runlayer Deploy lets you deploy them to managed infrastructure and register them as connectors — all from the CLI.

​
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, register, manage

​
How it works

1

Initialize

uvx runlayer login --host <runlayer-url>
uvx runlayer deploy init --host <runlayer-url>
This creates a deployment and generates a runlayer.yaml config file.
2

Configure and deploy

Edit runlayer.yaml with your service port, resources, and environment variables, then deploy:
uvx runlayer deploy --host <runlayer-url>
Runlayer builds your Docker image, pushes it, and deploys it to managed infrastructure.
3

Register as a connector

After deployment succeeds, open the deployment detail page in the Runlayer UI and click Register as MCP Server. Your deployed service is now a connector — browsable, assignable, and policy-enforced like any other connector.
For the full configuration reference, CLI commands, and examples, see the Deploy documentation.

​
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.
CatalogManualDeploy
Tool List GuardPre-scanned and reviewed by RunlayerScanned at registration, admin reviewsScanned at registration, admin reviews
Tool Call GuardYes, at runtimeYes, at runtimeYes, at runtime
Tool Intent GuardYes, at runtimeYes, at runtimeYes, at runtime
ToolGuard sensitivity can be configured globally in Settings → Security Scanners and overridden per connector. 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.

​
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

CatalogManualDeploy
Setup effortPre-filled formFill in formCLI + Dockerfile
Pre-scanned by RunlayerYesNoNo
Runtime security (ToolGuard)YesYesYes
Validated to workYesNoNo
Runs on Runlayer infraHosted STDIO connectorsHosted STDIO connectorsAll deployed connectors
Policy enforcementYesYesYes
Best forStandard integrationsExisting MCP endpointsCustom-built MCP servers
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.

​
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
  • Apply policies to control tool access
  • Monitor connector status and usage via analytics and audit logs

​
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

Runlayer Plugin

Get your first connector working in a client

Deploy

Deploy custom MCP servers to managed infrastructure

Policies

Control tool access with policies