Runlayer Plugin

Runlayer Plugin is Runlayer’s unified MCP entrypoint for your organization. Instead of asking users to install and manage many separate MCP servers, Runlayer Plugin gives them one standard connection that can discover and run the tools they already have access to in Runlayer. It is designed for teams that want broad tool access without broad tool sprawl: one install surface for users, one governance layer for admins, and one place for models to discover what they can actually use.

Runlayer Plugin is distinct from Runlayer MCP, the platform self-MCP for querying audit logs, analytics, and governance. Runlayer Plugin is the unified connector gateway: it exposes the active, hosted connectors your organization has added, subject to policy restrictions and your access grants. It does not expose local connectors, draft or disabled connectors, or tools your policies block.

What Runlayer Plugin Includes

Runlayer Plugin is a special Runlayer plugin that is built dynamically for each user. For each request, Runlayer builds that user’s Runlayer Plugin view from:

active hosted connectors the user can access through policies
accessible Runlayer skills
Runlayer platform tools exposed through the Runlayer MCP connector

Runlayer Plugin does not include:

local connectors that run on a user’s machine
draft or disabled connectors as normal executable tools
connectors blocked by policy for that user
tools the user could not use through the underlying connector directly

Runlayer Plugin does not grant new permissions. It only exposes capabilities the user already has through Runlayer, and every tool execution still goes through the underlying connector’s normal Runlayer controls.

Why teams use it

Runlayer Plugin is useful when your team wants a default, opinionated way to use MCP safely at scale. Without it, users often end up with fragmented client setup, duplicate connectors, inconsistent tool availability, and unclear security boundaries. Runlayer Plugin fixes that by giving the organization a single approved surface for tool discovery and execution. In practice, that means:

admins can standardize the MCP experience across teams
users get a simpler setup and fewer things to configure
models can search for the right tool when needed instead of carrying every tool definition in context
Runlayer policies, approvals, OAuth checks, ToolGuard, and audit logs stay in the loop

Find and connect Runlayer Plugin

Runlayer Plugin appears first in the default Plugins view. You can also reach it:

from the Add to Client flow for a connector or skill. When that connector or skill is included in Runlayer Plugin, Runlayer recommends the plugin before the direct, per-item setup instructions. Click Connect to open Runlayer Plugin with the same client selected.
from the My connectors or Skills page. Select one or more items and click Add to Client, then choose Use the Runlayer Plugin to connect the organization-wide plugin.

Direct connector and skill installation remains available when you need a separate client entry.

Admin rollout options

Give each supported AI client the same golden path to Runlayer. Enable Auto Sync for Runlayer Plugin, then complete the org install for every client your organization supports. Auto Sync keeps local client connections configured. Each org install adds the client-specific package or routing guidance.

Auto Sync

Open the Runlayer Plugin page in Runlayer, click Add to Organization, and enable Auto Sync. This adds Runlayer Plugin to supported local clients, including Cursor. For setup, verification, and MDM deployment, see Automatic Configuration Provisioning.

If you’ll be completing an Anthropic org install, exclude Claude Code from Auto Sync. With both active, Claude Code loads two Runlayer Plugin connections.

Org Installs

Complete the paths below for the clients your organization uses.

Anthropic org install

Install the Runlayer Plugin package through Claude admin plugin settings. The downloaded runlayer.zip contains:

runlayer/.claude-plugin/plugin.json
runlayer/.mcp.json
runlayer/skills/runlayer/SKILL.md

Download runlayer.zip

In Runlayer, open the Runlayer Plugin page, click Add to Organization, select Anthropic, and click Download zip.

Open Claude admin plugin settings

Go to Claude admin plugin settings and click Add plugin.

Claude admin plugin settings with the Add plugins button

Select Upload a file

Choose Upload a file.

Claude add plugins dialog with Upload a file selected

Upload the zip

Select runlayer.zip and click Upload.

Claude upload plugin dialog with runlayer.zip ready to upload

Require access

Change user access to Required.

Claude plugin settings with user access set to Required

OpenAI org install

Publish Runlayer Plugin and its skill to your ChatGPT organization. The downloaded runlayer.zip contains:

runlayer/SKILL.md
runlayer/agents/openai.yaml
runlayer/assets/runlayer-logo.svg

Open ChatGPT Admin Connectors settings

Go to ChatGPT Admin Connectors, enable developer mode, and click Create in Apps and Connectors.

Create the MCP connector

Use the values shown in the Runlayer dialog:

Field	Value
Name	`Runlayer Plugin`
Description	`Unified MCP server that provides access to all your organization's connectors, skills, plugins, and Runlayer platform tools.`
MCP Server URL	The URL shown in the Runlayer dialog
Authentication	OAuth

Complete the OAuth authorization when prompted.

Publish the connector

Publish the connector so it is available to your organization.

Review risks and configure confirmation

Review potential risks, mark them as reviewed, and configure action confirmation. For read-only actions, select Allow read actions with no user confirmation, then save.

Upload the Runlayer skill

Click Download zip in the Runlayer dialog. Go to chatgpt.com/skills, click + New skill, select Upload from your computer, and upload runlayer.zip.

Share the skill

Share the skill and set access to Installed for everyone.

Cursor org install

Auto Sync connects Runlayer Plugin in Cursor. Add a companion persistent rule so Cursor Agent stays on the preferred path when native integrations or local CLIs are also available. For organization-wide rollout, create a Team Rule in the Cursor dashboard and enforce it if users should not be able to disable it. For a smaller rollout, add the instructions as a User Rule in Cursor → Customize → Rules or commit an always-applied project rule such as .cursor/rules/runlayer-routing.mdc. For a project rule, start with:

---
description: Route external service work through Runlayer
alwaysApply: true
---

When a task may require an external service or organization-specific guidance:

- If a separately connected Runlayer-managed connector exposes the needed tool, use it directly.
- Otherwise, if Runlayer Plugin is available, call `search_tools` first, then call `execute_tool` with the exact tool name and arguments returned.
- When Runlayer Plugin's skill tools are available and organization-specific guidance may apply, call `search_skills` first when available, then use the returned IDs with `get_skill` and `get_skill_file`. Otherwise, use the legacy `get_skill` discovery flow, then call `get_skill_file` with the exact names returned.
- Do not use a Cursor-native integration or unmanaged local CLI for a service available through Runlayer.
- Never guess Runlayer tool names.
- If no Runlayer-managed path is available, or one returns an authentication failure or Runlayer denial, tell the user. Do not silently bypass it through an unmanaged path.

Team Rules and User Rules use the instruction body without the project-rule frontmatter. See Cursor Rules for rule scopes and management.

How tool discovery works

When a user connects Runlayer Plugin in their AI client, the model sees a compact interface instead of hundreds of raw tools. Runlayer Plugin exposes two meta-tools for connector tools, plus dedicated skills tools:

Tool	Purpose
`search_tools`	Search across the user’s accessible connector tools by describing the task.
`execute_tool`	Run a specific connector tool returned by `search_tools`.

The normal flow for connector tools is:

The model calls search_tools with the task it wants to accomplish.
Runlayer Plugin searches across the user’s accessible connectors and returns relevant tool definitions.
The model calls execute_tool with the exact returned tool name and arguments.
Runlayer routes the call to the underlying connector and applies the same policy, security, auth, and audit controls as a direct connector call.

search_tools searches connector tools only. Organization skills never appear in its results. Models should reach skills through the dedicated skills tools described below.

`search_tools`

Use search_tools before running connector tools. Inputs:

Argument	Required	Description
`meta`	When advertised	Why the model is searching. Use this for intent/context.
`query`	No	Natural-language description of the capability needed.
`top_k`	No	Number of results to return. Default is `5`, maximum is `10`.

Results include the exact tool name, description, source connector name, and input schema. Follow the input schema exposed by the client. Include meta only when that schema advertises it. Example for a schema that includes meta:

{
  "meta": "Need to create a GitHub issue for the deployment bug",
  "query": "create GitHub issue",
  "top_k": 5
}

`execute_tool`

Use execute_tool after selecting a tool from search_tools results. Inputs:

Argument	Required	Description
`meta`	When advertised	Why the model is executing this tool.
`tool_name`	Yes	Exact tool name returned by `search_tools`.
`arguments`	Yes	JSON object matching the returned input schema. Use `{}` if the tool takes no arguments.

Follow the input schema exposed by the client. Include meta only when that schema advertises it. Example for a schema that includes meta:

{
  "meta": "Create the issue the user requested",
  "tool_name": "create_issue",
  "arguments": {
    "repo": "acme/app",
    "title": "Deployment bug",
    "body": "Deployment failed after the latest release."
  }
}

If a model guesses a tool name, Runlayer Plugin returns a structured error with suggestions. The model should call search_tools again and use an exact name from the results.

Skills tools

Runlayer Plugin also exposes dedicated tools for organization skills — reusable instructions, playbooks, SOPs, and checklists. These sit alongside the connector meta-tools:

Tool	Purpose
`get_skill`	Find or inspect an organization skill relevant to the task.
`get_skill_file`	Read the full contents of a skill file.

Some organizations have an updated plugin surface that additionally exposes search_skills and list_skills, plus tools for creating and editing skills. The flow is the same everywhere: discover the relevant skill first, then read its files, then act on them. Because search_tools never returns skills, prompts and client instructions that want skills applied should direct the model at the skills tools, not at search_tools.

Skills and `/runlayer`

Runlayer Plugin install packages include a Runlayer skill that teaches supported clients how to use Runlayer Plugin. New install packages expose the MCP server as runlayer-plugin. Older organization installs may still expose the same server as onelayer; those installs continue to work because the proxy URL and plugin identity are unchanged. The skill tells the model to:

use Runlayer Plugin as the default entrypoint for tools, plugins, and skills
call search_tools before execute_tool
avoid guessing tool names
route external tool calls through Runlayer so security policies and audit logs remain in effect

In supported clients, this appears as an org-level /runlayer skill so users can ask for Runlayer tools and skills without installing separate prompt packages manually.

Permissions and security

Runlayer Plugin keeps the same security model as direct connector usage.

User-scoped results: each user sees only hosted connectors and skills they can access.
Policy-aware discovery: policy changes affect what appears in Runlayer Plugin on the next request.
Normal execution path: execute_tool delegates to the underlying connector proxy, so PBAC, ToolGuard, OAuth/session checks, and audit logging still apply.
OAuth preserved: if a connector needs user authorization, Runlayer Plugin can surface an auth-required tool instead of silently hiding the connector.
Partial results: if one connector is slow or temporarily unavailable, Runlayer Plugin can still return tools from other available connectors.

User examples

Once Runlayer Plugin is connected, users can ask their AI client for work in normal language. Examples:

“Use Runlayer to find the right GitHub tool and create an issue for this bug.”
“Search for Slack tools I can use, then summarize messages about the incident.”
“Use /runlayer to list available skills for release management.”
“Find the Salesforce tool for reading account details, then look up Acme.”

If the model cannot find a tool, ask it to search Runlayer Plugin first:

Search Runlayer Plugin for the tool you need before executing anything. Use the exact tool name from search results.

Troubleshooting

Runlayer Plugin is connected, but search_tools returns no tools

The user may not have access to any active hosted connectors. Check connector status and policies for that user. Local connectors are not included in Runlayer Plugin.

A connector I expected is missing

Runlayer Plugin only includes active hosted connectors visible to the user through policy. Draft, disabled, local, or policy-blocked connectors will not appear as normal executable tools.

Runlayer Plugin asks me to authenticate a connector

The underlying connector requires user OAuth or another user-scoped authorization. Complete the authorization, then search again.

The model guessed a tool name and failed

Ask it to call search_tools first. Runlayer Plugin tool names must match the names returned by search results.

The model uses search_tools but never finds my skills

search_tools searches connector tools only; skills never appear in its results. Ask the model to use the plugin’s skills tools instead — get_skill to find the relevant skill (or search_skills where available), then get_skill_file to read it. If a skill is still missing, confirm the user has access to it on the Skills page.

One connector is down, but others still appear

Runlayer Plugin is best-effort during discovery. If one connector times out or returns a non-auth error, Runlayer Plugin can still return tools from other available connectors.

Plugins

Learn how dynamic tools work for Runlayer plugins.

Policies

Control which users can access each connector and tool.

Audit Logs

Review Runlayer Plugin and connector activity.

Skills

The end-to-end flow from a skill in your repo to Claude and Cursor.

Enable

Control

Self-Hosted Deployment

Operations

Cookbook

Integrations

Connectors

Resources

What Runlayer Plugin Includes

Why teams use it

Find and connect Runlayer Plugin

Admin rollout options

Auto Sync

Org Installs

Anthropic org install

OpenAI org install

Cursor org install

How tool discovery works

`search_tools`

`execute_tool`

Skills tools

Skills and `/runlayer`

Permissions and security

User examples

Troubleshooting

Plugins

Policies

Audit Logs

Skills

​What Runlayer Plugin Includes

​Why teams use it

​Find and connect Runlayer Plugin

​Admin rollout options

​Auto Sync

​Org Installs

​Anthropic org install

​OpenAI org install

​Cursor org install

​How tool discovery works

​search_tools

​execute_tool

​Skills tools

​Skills and /runlayer

​Permissions and security

​User examples

​Troubleshooting

​Related docs

Plugins

Policies

Audit Logs

Skills

What Runlayer Plugin Includes

Why teams use it

Find and connect Runlayer Plugin

Admin rollout options

Auto Sync

Org Installs

Anthropic org install

OpenAI org install

Cursor org install

How tool discovery works

`search_tools`

`execute_tool`

Skills tools

Skills and `/runlayer`

Permissions and security

User examples

Troubleshooting

Related docs