Runlayer Plugin

​

What Runlayer Plugin Includes

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

• 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

​

Why teams use it

• admins can standardize the MCP experience across teams
• users get a simpler setup and fewer things to configure
• models get connector tools in the form best suited to their client’s discovery capabilities
• Runlayer policies, approvals, OAuth checks, ToolGuard, and audit logs stay in the loop

​

Find and connect Runlayer Plugin

• 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 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.

​

Admin rollout options

​

Auto Sync

​

Org Installs

​

Anthropic org install

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

1

Download runlayer.zip

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

2

Open Claude admin plugin settings

Go to Claude admin plugin settings and click Add plugin.

3

Select Upload a file

Choose Upload a file.

4

Upload the zip

Select runlayer.zip and click Upload.

5

Add the connector

Claude then asks to add the plugin’s connector. Click Add, then Done.If you cancel this prompt, the plugin installs without its connector and Claude can’t reach Runlayer. Remove the plugin and upload runlayer.zip again.

6

Require access

Change user access to Required.

7

Connect each user

Each user goes to Customize → Connectors in Claude (Settings → Connectors in older versions) and clicks Connect on the Runlayer connector to sign in. Until they do, Claude can’t call Runlayer tools. After that, the connector must also be on in the chat; see Turn it on in a Claude chat.

​

OpenAI org install

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

​

Cursor org install

---
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 advertises the needed connector tool directly, use it.
- Otherwise, if Runlayer Plugin exposes `search_tools` and `execute_tool`, call `search_tools` first, then call `execute_tool` with the exact tool name and arguments returned.
- When organization-specific guidance may apply, call `search_skills` first (or `list_skills` to browse), then use the returned IDs with `get_skill` and `get_skill_file`.
- When work may be delegated, call `list_agents`, inspect a candidate with `get_agent`, then call `run_agent`.
- 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.

​

How connector tools are presented

{
  "type": "http",
  "url": "https://<your-runlayer-host>/api/v1/proxy/plugins/<plugin-id>/mcp",
  "headers": { "X-Runlayer-Tool-Exposure": "force-initial" }
}

​

Nested connector discovery

1. The model calls search_tools with the task it wants to accomplish.
2. Runlayer Plugin searches across the user’s accessible connectors and returns relevant tool definitions.
3. The model calls execute_tool with the exact returned tool name and arguments.
4. 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

{
  "query": "create GitHub issue",
  "top_k": 5
}

​

execute_tool

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

​

Skills tools

​

Agent tools

​

Artifact tools

​

Skills and /runlayer

• use Runlayer Plugin as the default entrypoint for tools, plugins, skills, and agents
• call a directly advertised connector tool when available, or call search_tools before execute_tool when nested discovery is available
• use search_skills or list_skills, then get_skill and get_skill_file, for workspace guidance
• use list_agents, get_agent, and run_agent for delegation
• avoid guessing tool names
• route external tool calls through Runlayer so security policies and audit logs remain in effect

​

Permissions and security

• 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: direct connector tools and execute_tool both delegate to the underlying connector proxy, so PBAC, ToolGuard, OAuth/session checks, and audit logging still apply.
• Platform tools follow policy too: skill, agent, and artifact tools, including the delete tools, run through the Runlayer MCP server’s normal proxy path and are allowed by default. confirm=true is set by the model, not by a person, so it is not an approval step. To restrict these tools, add a deny policy: org-wide with Block Destructive Tools, which matches the delete tools; only when an agent is acting, with meta.actor.id regex .+; or only when reached through a plugin, with meta.plugin.id regex .+. update_artifact and edit_artifact can replace an artifact’s content but are not marked destructive, so deny them by name if you need to.
• 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.

​

Unattended automation and scheduled jobs

1. Pick the user the automation runs as. For shared automation, use a dedicated account (for example a service account in your identity provider) rather than a person’s, so jobs don’t stop when someone leaves. Give it only the access the jobs need with policies; Runlayer Plugin shows it only what those policies allow, and every call is audited as that user.
2. Authorize its connectors once. Sign in to Runlayer as that user, open Connectors, and click Connect on every OAuth connector the jobs call. Otherwise the first call returns an AUTH_REQUIRED_<connector> tool or an authorization link instead of data, and an unattended job stalls there. See Authorizing at use time.
3. Authenticate the automation client in one of two ways:
   • Personal API key (no browser at all). While signed in as that user, create a key in Settings → Personal API keys, then send it in the x-runlayer-api-key header to https://<your-runlayer-host>/mcp:
     {
       "mcpServers": {
         "runlayer-plugin": {
           "type": "http",
           "url": "https://<your-runlayer-host>/mcp",
           "headers": { "x-runlayer-api-key": "<the user's personal API key>" }
         }
       }
     }
     
     Personal API keys don’t expire. They stop working when they’re revoked on the same settings page or when the user is deactivated. Organization API keys are rejected here with 403 Organization API keys are not supported on this endpoint, because Runlayer Plugin needs a user.
   • OAuth once, then refresh. If the client supports MCP OAuth and stores its tokens, complete the browser sign-in once. Runlayer issues a 2-hour access token and a refresh token that stays valid for 30 days after its last use, so a job that runs at least once a month keeps working without a person. It has to sign in again only if the token goes unused for 30 days or the user is deactivated.

​

User 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.”

Check Runlayer Plugin for the tool you need. Call an advertised connector tool directly, or use search_tools and execute_tool when they are available. Never guess a tool name.

​

Turn it on in a Claude chat

1. Sign in once. In Claude, open Customize → Connectors and click Connect on the Runlayer connector.
2. Check it’s on in the chat. Click + at the bottom left of the message box, open Connectors, and make sure the Runlayer connector is switched on. The switch is per conversation, so check it first when a chat can’t find Runlayer tools.
3. Ask for the work. Naming Runlayer (or /runlayer, where the org skill is installed) is optional, but it helps when another connector in the chat offers a similar tool.

​

Troubleshooting

​

Related docs