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

​

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

Require access

Change user access to Required.

​

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

​

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

​

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

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

​

Troubleshooting

​

Related docs