CloudPeek Plugin

Connects your agent to the hosted CloudPeek MCP gateway and teaches it CloudPeek's incident triage and investigation workflows, so it works your queue like an analyst who has read the runbook rather than one poking at an unfamiliar API.

Installation

Pick your client. Every route below reaches the same endpoint; installing the plugin package rather than just the MCP server is what gets you the two skills as well as the tools. Whichever route you take, the browser sign-in described in Signing in happens on first connection.

Claude Code

/plugin marketplace add Cloud-Peek/agent-plugin

/plugin install cloudpeek@cloudpeek-plugins

To add only the MCP server, without the skills:

claude mcp add --transport http cloudpeek https://app.cloudpeek.ai/mcp

VS Code and GitHub Copilot

Run Chat: Install Plugin From Source and give it https://github.com/Cloud-Peek/agent-plugin, or browse the Extensions view with the @agentPlugins filter.

To add only the MCP server, put this in .vscode/mcp.json:

{
  "servers": {
    "cloudpeek": {
      "type": "http",
      "url": "https://app.cloudpeek.ai/mcp"
    }
  }
}

Note there is no credential in that block, and there should not be one. The sign-in happens in the browser on first connection.

Cursor

Install the plugin from Customize in the sidebar, or add the repository as a team marketplace under Dashboard → Plugins → Import from Repo.

To add only the MCP server, put this in .cursor/mcp.json for a single project, or in ~/.cursor/mcp.json for every project:

{
  "mcpServers": {
    "cloudpeek": {
      "url": "https://app.cloudpeek.ai/mcp"
    }
  }
}

Codex

Codex reads the portable package directly, so installing from the repository gives you both the server and the skills. To wire up the server on its own, add it to your Codex MCP configuration as a Streamable HTTP server pointing at https://app.cloudpeek.ai/mcp, with no static credential.

OpenCode

OpenCode plugins are JavaScript modules rather than manifest bundles, so this installs as an MCP server. Add to opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "cloudpeek": {
      "type": "remote",
      "url": "https://app.cloudpeek.ai/mcp",
      "enabled": true
    }
  }
}

Kiro, Grok Bot, OpenClaw, NanoClaw and Hermes Agent

These all load the portable package directly. Follow the setup instructions on the compatible clients list and point the client at https://github.com/Cloud-Peek/agent-plugin.

Any other MCP client

Point it at https://app.cloudpeek.ai/mcp over Streamable HTTP. Most clients accept a generic remote-server block equivalent to:

{
  "mcpServers": {
    "cloudpeek": {
      "type": "streamable-http",
      "url": "https://app.cloudpeek.ai/mcp"
    }
  }
}

A third-party client needs three capabilities to connect, and it is worth checking all three before you start:

• Streamable HTTP. POST only, one JSON-RPC message per request. The gateway offers no server-initiated SSE stream: a GET returns 405 with Allow: POST, DELETE. There is no hosted stdio variant either, so a client that cannot do Streamable HTTP cannot connect.
• OAuth 2.1 authorisation code with PKCE. S256 is the only challenge method offered.
• Dynamic client registration (RFC 7591). The gateway issues no credentials ahead of time, so a client that cannot register itself has no way in.

Clients that do all three need no manual configuration beyond the URL: they find everything else themselves from the metadata documents.

https://app.cloudpeek.ai/.well-known/oauth-protected-resource/mcp
https://app.cloudpeek.ai/.well-known/oauth-authorization-server/mcp

Those advertise the authorisation, token and registration endpoints. Root-level /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server are served too, for clients that predate the path-aware form.

The access token goes in the Authorization: Bearer header. That is the only accepted position: there is no query-string or form-body token.

Signing in

The plugin ships no credentials, and there is no token for you to generate, copy or paste. On first connection your client does the whole thing itself:

1. It fetches the gateway's OAuth 2.1 metadata from the endpoint.
2. It registers itself dynamically, obtaining its own client credentials. You do not pre-create an application or client ID anywhere in CloudPeek.
3. Your browser opens and you sign in to your CloudPeek tenant, exactly as you would to the web app, including SSO if your organisation uses it.
4. The client receives an access token, stores it in its own credential store, and reconnects.

From then on the agent sees exactly what your CloudPeek user sees, enforced server-side.

About the token

Your client holds an access token, so it is worth being clear about what that is and is not.

It is issued to the client, not to you to hand around. The token is minted at the end of the browser flow and written to whatever credential store your client uses. It is not shown in the CloudPeek UI, and there is no page where you generate one manually.

There is no personal access token, API key or static bearer token. If a guide or a config template asks you to paste a CloudPeek MCP token, it is describing something that does not exist. Leave the credential field out entirely rather than inventing a placeholder.

It expires, and the client refreshes it. Access tokens are short-lived, an hour by default, and the client renews them with a longer-lived refresh token that rotates on each use. You may still be asked to sign in again periodically. That is the flow working, not a fault.

It carries your identity. Anything the agent does through this plugin is attributed to your CloudPeek user and lands in the audit trail under your name, so treat a machine with a live token the way you would treat one with your browser session open.

Revoking access

Revoke a client's access at any time from your CloudPeek settings, described in Admin & Settings. Revocation is server-side and immediate: it does not depend on the client cooperating, which is what you want if a laptop goes missing.

What the agent can do

The gateway exposes the CloudPeek API as MCP tools: incidents, investigations, artifacts, runbooks, the wiki and more. The API Overview is the fullest description of that surface.

Two properties matter more than the tool list.

Access is scoped to your user. This is the same permission model as the web app, covered in Permissions Overview. Connecting an agent does not widen what you can reach; an agent acting for you cannot see a tenant, incident or tool you could not open yourself.

Consequential actions stop for approval. Evidence gathering is read-only. Anything that would change your estate goes through the same human-in-the-loop gate as the rest of CloudPeek, described in Human-in-the-Loop (HITL). An agent working through this plugin proposes a remediation; it does not quietly perform one.

Verifying the install

Ask your agent something that needs the tenant:

Show me the open incidents in CloudPeek.

If the plugin is connected but you have not yet signed in, this is what triggers the browser flow. Once signed in, you should get your actual queue back.

If the client reports no tools, check that it supports Streamable HTTP and that your network allows outbound HTTPS to app.cloudpeek.ai. If it connects but every call is rejected, the sign-in did not complete: look for a pending browser window, or ask the client to re-authenticate.

Two status codes are worth recognising if you are debugging a client by hand:

• 401 means the token is missing, expired or invalid. The response carries a WWW-Authenticate: Bearer header pointing at the protected-resource metadata, which is the signal a well-behaved client uses to start the sign-in flow by itself.
• 403 before any sign-in happens usually means the Origin header was rejected. The gateway restricts origins to protect against DNS rebinding, so a browser-based client needs its origin allowed; a normal desktop or CLI client sends no Origin and is unaffected.

Skills

Two skills ship with the plugin. They load on demand: your agent reads their descriptions, and when a request matches one it pulls in the full instructions. You do not invoke them by name, though you can ask for one explicitly.

triage-incidents

Triage CloudPeek incidents so the operator only sees the small fraction of alerts that matter.

Loads when you ask the agent to review, prioritise, assign or summarise open incidents.

CloudPeek has already clustered raw alerts into incidents and enriched them, so most noise is suppressed before triage begins. The skill's job is to confirm what actually deserves human attention rather than re-reviewing every alert from scratch. It leaves an audit comment trail as it goes, so the reasoning behind each call is recoverable later.

Related reading: Incident Management and Automatic Triage.

investigate-incident

Run a structured CloudPeek investigation on an incident, gather artifacts and evidence, and produce a report with remediation options.

Loads when you ask the agent to investigate, dig into, or write up an incident.

An investigation is CloudPeek's durable record of the questions asked about an incident and the evidence found in answer. The skill deliberately works inside that record rather than in ad-hoc chat, so the findings survive the session and stay reviewable by someone who was not there. Remediation is proposed, never silently applied.

Related reading: Investigations and Artifacts.

Versions and updates

The package is mirrored from the CloudPeek monorepo, which is the source of truth, and its version tracks the CloudPeek application release it was published from.

Because the endpoint is hosted, tool changes reach you without reinstalling anything. Refresh the marketplace only to pick up new or changed skills.