# Rubrik Security Cloud (pypi · rubrik-mcp)

Connect AI assistants to the Rubrik Security Cloud GraphQL API to discover, query, and automate.

- Trust score: 78/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-04

## Components

- pypi · `rubrik-mcp`: 78/100 (this document), [markdown](https://verifymcp.io/servers/rubrikinc-rubrik-mcp/rubrik-mcp.md), [page](https://verifymcp.io/servers/rubrikinc-rubrik-mcp/rubrik-mcp)

## Channel facts

- Registry: `pypi`
- Package: `rubrik-mcp`
- Version: `0.8.20260928`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-04.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs hatchling.build at install time, a recognised build step with no custom scripting around it.
  - 1 of 38 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 97/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to rubrikinc/rubrik-mcp).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 1 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 63/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 5759 tokens (~443/item across 13 items; 13 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 13/100
  - Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (8% of tools); any adoption earns full credit.
- **Tool Safety**: 88/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 1 of 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "rsc_execute_operation" implies "execute" and declares readOnlyHint instead, contradicting what its own name says it does.
  - An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Rubrik Security Cloud MCP server?

Rubrik Security Cloud runs locally as a PyPI package, launched with uvx rubrik-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add rubrikinc-rubrik-mcp -- uvx rubrik-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "rubrikinc-rubrik-mcp": {
      "command": "uvx",
      "args": [
        "rubrik-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "rubrikinc-rubrik-mcp": {
      "command": "uvx",
      "args": [
        "rubrik-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add rubrikinc-rubrik-mcp -- uvx rubrik-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "rubrikinc-rubrik-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "rubrik-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add rubrikinc-rubrik-mcp --command uvx --arg rubrik-mcp
```

### Hermes

```yaml
mcp_servers:
  rubrikinc-rubrik-mcp:
    command: "uvx"
    args: ["rubrik-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "rubrikinc-rubrik-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "rubrik-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add rubrikinc-rubrik-mcp -t stdio -c uvx -a rubrik-mcp
```

### Other

```json
{
  "mcpServers": {
    "rubrikinc-rubrik-mcp": {
      "command": "uvx",
      "args": [
        "rubrik-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-04 (score 78, +16)

- [security improvement] Malware scan: unverified → pass

### 2026-10-03 (score 62, −15)

- [security regression] Malware scan: pass → unverified

### 2026-10-02 (score 77, +16)

- [security improvement] Malware scan: unverified → pass
- [functional improvement] Stability: unverified → 0.07
- [functional] Package version: 0.8.20260914 → 0.8.20260928

### 2026-09-30 (score 61)

First indexed and scored.

## MCP tools (13)

### `rsc_search_schema` (~303 tokens)

Search the full RSC GraphQL schema to find relevant operations.

Searches operation names/descriptions, field semantics, and type-level
vocabulary in one call and returns the best candidate operations ranked
by relevance. Use this whenever you need to find an operation and don't
already know its name.

The search runs three complementary indexes:
\- Operation index: matches operation names and descriptions directly
\- Field index: finds concepts buried in nested type fields (e.g.
  "who is logged in" → Group.activeUsers → operations returning Group)
\- Type index: matches domain concepts to operations via aggregate type
  vocabulary (e.g. "cluster storage runway" → Cluster type → listing ops)

Results are deduplicated and merged; the same operation may be surfaced
by multiple indexes and will appear once with the highest score.

Args:
    search: Natural-language query or keywords describing what you want.
        Must be non-empty. Use descriptive terms, not operation names.
    operation_type: Filter results to "query", "mutation", or "all"
        (default). Use "query" for read-only intent, "mutation" for
        write intent.

Returns:
    Dict with:
      - operations: list of dicts with name, type, description,
        return_type, score, source (ops/fields/types)
      - search: the search string used

Input parameters:

- `operation_type` (string)
- `search` (string, required)

### `rsc_describe_type` (~108 tokens)

Get the definition of a GraphQL type used in RSC operations.

Args:
    name: Type name (e.g. "CreateGlobalSlaInput", "SlaAssignTypeEnum").

Returns:
    Dict with name, kind, and either:
      - fields: {fieldName: {type, description}} for objects/inputs/interfaces
      - values: [str] for enums
      - types: [str] for unions

Input parameters:

- `name` (string, required)

### `rsc_describe_operation_full` (~266 tokens)

Get an operation's signature with all input types expanded inline.

Returns an operation's argument signature with all input/enum types
expanded inline — recursively up to `depth` levels. Combines the
operation lookup and rsc_describe_type into one call so you have
everything needed to construct a correct query without guessing.

Args:
    name: camelCase operation name (e.g. "azureNativeVirtualMachines").
    operation_type: "query" or "mutation".
    depth: How many levels of input types to expand (default 2).

Returns:
    Dict with operation details plus:
      - "expanded_types": all referenced input/enum type definitions
      - "return_type_fields": object/interface types in the return type,
        expanded 2 levels deep (connection wrapper → node fields), so
        you know exactly which fields are selectable in the query body.
        Interface types include an "inline_fragments" key listing each
        concrete implementor and its fields — these fields are ONLY
        accessible via "... on TypeName { field }" inline fragments in
        your query; they cannot be queried directly on the interface.

Input parameters:

- `depth` (integer)
- `name` (string, required)
- `operation_type` (string, required)

### `rsc_get_workloads` (~995 tokens)

List workloads with protection, compliance, usage, and backup status.

Each result includes:
  \- Identity: fid, name, objectType
  \- SLA: slaDomain (assigned SLA), protectionStatus (Protected/NoSla/DoNotProtect)
  \- Compliance: complianceStatus (IN_COMPLIANCE, OUT_OF_COMPLIANCE, etc.)
  \- Backup history: lastSnapshot, localSnapshots, missedSnapshots, totalSnapshots
  \- Usage: physicalBytes, logicalBytes
  \- Location: location (e.g. vCenter, host, or instance the workload lives on),
              cluster (Rubrik cluster managing the workload)

Args:
    object_type: Filter by workload type, e.g. "NutanixVirtualMachine",
        "VmwareVirtualMachine", "AzureNativeVm", "AwsNativeEc2Instance".
        Cannot be combined with excluded_object_types.
    protection_status: One of "Protected", "NoSla", "DoNotProtect".
        Omit to return all statuses.
    search_term: Filter by name substring.
    compliance_status: Filter by compliance state. One of:
        "IN_COMPLIANCE" — protected, active, no missed snapshots.
        "OUT_OF_COMPLIANCE" — protected, active, one or more missed snapshots.
        "UNPROTECTED" — no effective SLA assigned.
        "NOT_APPLICABLE" — protected but relic or archived; compliance not evaluated.
        "NOT_AVAILABLE" — protected and active but compliance could not be computed
            (SLA engine error or unmet precondition).
        "EMPTY" — report sync has not yet produced a value for this object;
            data is absent, not wrong. Indicates the cluster's report sync is lagging.
        Note: "NULL" also exists in the underlying store but is excluded from this
            filter — it indicates a workload with no compliance status object at all
            (distinct from EMPTY) and is not used in practice by the ETL pipeline.
    sla_time_range: Compliance window to evaluate. Defaults to the entire
        protection lifetime of each workload, which often overstates
        violations. Prefer a shorter window for actionable r…

Input parameters:

- `cluster_id`
- `compliance_status`
- `excluded_object_types`
- `is_local`
- `limit`
- `object_fids`
- `object_state`
- `object_type`
- `org_id`
- `protection_status`
- `search_term`
- `sla_id`
- `sla_time_range`
- `sort_by`
- `sort_order`

### `rsc_search_help` (~287 tokens)

Search Rubrik KB articles, product documentation, and known issues.

Use when: an RSC event or workload has a failure/error message, the user
asks a troubleshooting or "how do I" question, or an error code (e.g.
RBK91030123) is present. Always call this before answering from memory —
KB articles reflect the current product state. Results include title,
description snippet, source type, and a direct link to the full article.

Args:
    query: Free-text search string (e.g. "ransomware recovery", "SLA not applying").
    source: Limit results to one source. One of: KB_ARTICLES, PRODUCT_DOCS,
        KNOWN_ISSUES. Omit to search all sources.
    limit: Maximum number of results to return. Default 10.

Returns:
    A dict with `count` (total matches), `returned` (how many results are in
    this response), `truncated` (True when more results exist than were returned),
    and `results` (list of items with title, source, description, and link).
    Report `count` for "how many" questions, not `len(results)`. Note: `link`
    may be null for some results.

Input parameters:

- `limit` (integer)
- `query` (string, required)
- `source`

### `rsc_get_events` (~420 tokens)

Get recent events and activity for workloads.

Returns backup jobs, failures, anomalies, and other activity. Always
scoped to a time window (default: last 24 hours) to keep queries fast.

For failure details, each event includes the error message, reason, and
recommended remedy where available.

Args:
    last_hours: How far back to look, in hours. Default 24. Always
        provide this — omitting a time range makes the query very slow.
    workload_id: Filter to a specific workload FID (from rsc_get_workloads).
        Use this to answer "why did the backup fail for workload X".
    object_name: Filter by object name substring.
    status: Filter by event status. One of: SUCCESS, FAILURE, WARNING,
        RUNNING, CANCELED, CANCELING, QUEUED, PARTIAL_SUCCESS,
        TASK_FAILURE, TASK_SUCCESS, INFO.
    severity: Filter by severity. One of: SEVERITY_CRITICAL,
        SEVERITY_WARNING, SEVERITY_INFO.
    activity_type: Filter by activity type. Common values: BACKUP,
        RECOVERY, REPLICATION, ARCHIVE, ANOMALY, INDEX, LOG_BACKUP.
    cluster_id: Filter by Rubrik cluster UUID.
    limit: Maximum number of events to return. Default 100.

Returns:
    A dict with `count` (true total matching the filter), `returned` (how
    many events are in this response), `truncated` (True when more events
    exist than were returned, because of `limit` or the record cap), and
    `events` (the list of event records). Report `count` for "how many"
    questions, not `len(events)`.

Input parameters:

- `activity_type`
- `cluster_id`
- `last_hours` (number)
- `limit` (integer)
- `object_name`
- `severity`
- `status`
- `workload_id`

### `rsc_get_clusters` (~325 tokens)

List Rubrik CDM clusters registered in RSC. Use for any question about cluster
inventory, connection status (connected/disconnected/degraded), CDM version, storage
capacity, runway, sync health, node health, or hardware warnings.
Filters: name, connection status, cluster type.

Each result includes:
  \- Identity: id, name, version, type, productType
  \- Status: status (Connected/Disconnected/Initializing), isHealthy
  \- Capacity: metric.totalCapacity, usedCapacity, availableCapacity (bytes)
  \- Runway: estimatedRunway (days before storage is full)
  \- Nodes: clusterNodeConnection.count (number of nodes in the cluster)
  \- Timing: lastConnectionTime

Args:
    name_contains: Filter by cluster name. Passed to the server-side name filter.
    status: Connection status filter. One of: Connected, Disconnected, Initializing.
    cluster_type: Cluster type filter. One of: Cloud, ExoCompute, OnPrem, Polaris,
        Robo, Unknown.
    limit: Maximum number of clusters to return. Default 20, max 100.

Returns:
    A dict with:
      - count: true total matching the filter (the connection's `count`).
      - returned: how many clusters are in this response.
      - truncated: True when returned < count (more exist than were returned).
      - clusters: list of cluster records.

Input parameters:

- `cluster_type`
- `limit` (integer)
- `name_contains`
- `status`

### `rsc_get_sla_domains` (~464 tokens)

List SLA Domains (protection policies) configured in RSC. Use for any question
about protection policies — filter by name, protected workload type (including
Kubernetes), cluster, or retention lock status. Also use for: counting SLA policies,
finding which SLAs protect a specific workload type, identifying retention-locked SLAs,
or finding SLAs with specific replication or archival configurations.

Each result includes:
  \- Identity: id, name, description
  \- Object types: objectTypes (SlaObjectType enum values for workloads this SLA covers)
  \- Coverage: protectedObjectCount (number of workloads under this SLA)
  \- Retention lock: isRetentionLockedSla, retentionLockMode
  \- Base frequency: baseFrequency.duration + unit (primary backup schedule)
  \- Archival: archivalSpecs (target name, type, and frequency threshold)
  \- Replication: replicationSpecsV2 (destination cluster IDs and names)

Args:
    name_contains: Filter by SLA name (server-side name filter).
    object_type: Filter by protected workload type. Must be a SlaObjectType enum
        value, e.g. "VSPHERE_OBJECT_TYPE", "K8S_OBJECT_TYPE",
        "AWS_EC2_EBS_OBJECT_TYPE", "NUTANIX_OBJECT_TYPE".
    cluster_id: Filter by cluster UUID — returns SLAs associated with that cluster.
    is_retention_locked: When True, return only retention-locked SLAs. When False,
        return only non-retention-locked SLAs. Omit to return all. Applied
        client-side after fetching; `count` reflects the server-side total before
        this filter.
    limit: Maximum number of SLA domains to return. Default 50, max 200.

Returns:
    A dict with:
      - count: true total matching the server-side filter (before is_retention_locked).
      - returned: how many SLA domains are in this response.
      - truncated: True when returned < count.
      - sla_domains: list of SLA domain records.

Input parameters:

- `cluster_id`
- `is_retention_locked`
- `limit` (integer)
- `name_contains`
- `object_type`

### `rsc_wait_for_job` (~464 tokens)

Poll an RSC job until it completes and return the final status.

Handles all job types automatically based on objectType — no polling
code needed from the caller.

How to get job_id and cluster_id:
  \- CDM workloads: job_id = the `id` field from the AsyncRequestStatus
    returned by the snapshot mutation. cluster_id = the `cluster_id` field
    returned by rsc_take_on_demand_snapshot (included automatically for CDM
    types). Falls back to cluster.id from rsc_get_workloads if needed.
  \- Cloud-native workloads: job_id = `taskchainUuid` from
    `taskchainUuids[0].taskchainUuid` in the mutation response.
    cluster_id is not needed.

For background monitoring without blocking, run rsc-job-monitor via
the Bash tool and watch it with the Monitor tool:
  Bash(run_in_background=true):
    /usr/local/bin/rubrik-job-monitor --job-id <id> --object-type <type> [--cluster-id <uuid>]
  Monitor(command):
    /usr/local/bin/rubrik-job-monitor --job-id <id> --object-type <type> [--cluster-id <uuid>]

Args:
    job_id: Request ID (CDM) or taskchainUuid (cloud-native).
    object_type: Workload objectType — determines which status query to use.
    cluster_id: Rubrik cluster UUID. Required for CDM workloads.
        Get it from rsc_get_workloads cluster.id.
    timeout: Maximum seconds to wait before returning. Default 300.
    poll_interval: Seconds between status checks. Default 10.

Returns:
    Dict with status, progress, done, raw, and optionally timed_out.
    CDM status values: SUCCEEDED, FAILED, CANCELED, QUEUED, IN_PROGRESS.
    Cloud-native state values: SUCCEEDED, FAILED, CANCELED, RUNNING, READY.
    jobInfo status values: SUCCESS, FAILURE, IN_PROGRESS, UNSPECIFIED.

Input parameters:

- `cluster_id`
- `job_id` (string, required)
- `object_type` (string, required)
- `poll_interval` (integer)
- `timeout` (integer)

### `rsc_execute_operation` (~372 tokens)

Execute a raw GraphQL query against the live RSC API.

This tool supports queries only. Mutations are not available via raw GraphQL — use built-in tools (rsc_take_on_demand_snapshot, etc.) for supported write operations. If you submit a mutation, this tool returns a mutation_blocked error with the attempted operation so Claude can generate a Python code sample for you.

IMPORTANT: Write `operation` as a single line with no newlines or extra
whitespace. Multi-line strings appear as ugly \n escape sequences in the
tool call display. Good: "query { nodes { id name } }"

Requires RSC credentials — set one of:
  \- RSC_SERVICE_ACCOUNT_FILE env var (path to service account JSON)
  \- RSC_URL + RSC_CLIENT_ID + RSC_CLIENT_SECRET env vars
  \- ~/.rsc/config.json

Args:
    operation: A complete GraphQL query string on a single line, e.g.:
        "query { accountId }"
        "query ListSLAs($after: String) { slaDomains(after: $after) { count nodes { id name } pageInfo { hasNextPage endCursor } } }"
    variables: Optional dict of variable values for parameterized operations.

Returns:
    The raw JSON response from the RSC GraphQL API (data + errors if any).
    Returns {"error": "mutation_blocked", "blocked_operation": "...", "message": "..."}
    if a mutation is submitted — Claude will use this to generate a Python code sample.

Note: returns the raw GraphQL response with no field filtering or redaction — do not use in contexts where data minimization of personal-data-bearing fields is required.

Input parameters:

- `operation` (string, required)
- `variables`

### `rsc_save_workflow` (~463 tokens)

Save a multi-step workflow as a named, callable MCP tool.

Call this after completing a workflow in conversation to persist it for
future use. The workflow is written to the workflows/ dir under the MCP
config directory (~/.config/rubrik-mcp/workflows/ by default, or under
$RUBRIK_MCP_CONFIG_DIR when set) and registered immediately. It loads
automatically on next server start. The exact file path is returned in the
response.

Provide either `spec` (the complete workflow dict) or `steps` + the other
fields individually. Passing `spec` is simpler when the LLM has already
constructed the full definition.

Workflow spec format:
    {
      "schema_version": 1,
      "name": "rsc_my_workflow",
      "description": "What this does and when to use it.",
      "steps": [
        {
          "id": "step1",
          "mcp": "rubrik",
          "tool": "rsc_execute_operation",
          "args": {"operation": "query { accountId }"}
        },
        {
          "id": "step2",
          "mcp": "virustotal",
          "tool": "get_threat_actor_files",
          "args": {"threat_actor_id": "${step1.data.accountId}"}
        }
      ]
    }

RSC steps ("mcp": "rubrik") execute server-side.
Non-RSC steps are returned as next_steps for the LLM to execute.
Use "${step_id.path.to.value}" in args to reference prior step results.

Args:
    name: Tool name (valid Python identifier, e.g. "rsc_get_aws_failures").
    description: What this workflow does and when to use it.
    steps: List of step dicts (id, mcp, tool, args).
    spec: Complete workflow spec dict — use instead of name/description/steps
          when passing the full definition at once.

Returns:
    Dict with status, name, path, and a note about restart behavior.

Input parameters:

- `description` (string, required)
- `name` (string, required)
- `spec`
- `steps`

### `rsc_list_workflows` (~75 tokens)

List all user-defined workflows in the MCP config dir's workflows/ folder.

Location is ~/.config/rubrik-mcp/workflows/ by default, or under $RUBRIK_MCP_CONFIG_DIR
when set. Returns name, description preview, step count, and the resolved file
path for each workflow.

Output parameters:

- `result` (array)

### `rsc_delete_workflow` (~122 tokens)

Delete a user-defined workflow from the MCP config dir's workflows/ folder.

Location is ~/.config/rubrik-mcp/workflows/ by default, or under $RUBRIK_MCP_CONFIG_DIR
when set. Removes the workflow file from disk. The workflow remains callable
in the current server session but will not load on next restart.

Args:
    name: The workflow name (as returned by rsc_list_workflows).

Returns:
    Dict with status, name, and path of the deleted file.

Input parameters:

- `name` (string, required)

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/rubrikinc-rubrik-mcp/rubrik-mcp#diagnostics

## Score history

- 2026-10-04: 78
- 2026-10-03: 62
- 2026-10-02: 77
- 2026-10-01: 61
- 2026-09-30: 61

## Common questions

### What is the Rubrik Security Cloud MCP server?

Rubrik Security Cloud is an MCP server listed in the public MCP registry as io.github.rubrikinc/rubrik-mcp. Connect AI assistants to the Rubrik Security Cloud GraphQL API to discover, query, and automate. This page covers its PyPI package (rubrik-mcp).

### Is the Rubrik Security Cloud MCP server safe to use?

Rubrik Security Cloud scores 78 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 4 October 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Rubrik Security Cloud MCP server expose?

Rubrik Security Cloud exposes 13 tools: rsc_search_schema, rsc_describe_type, rsc_describe_operation_full, rsc_get_workloads, rsc_search_help, and 8 more. Their descriptions and schemas cost roughly 4,664 tokens of context every time the server is loaded.

### Is the Rubrik Security Cloud MCP server still maintained?

Rubrik Security Cloud is still listed as active in the MCP registry. We last reached this channel on 4 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Rubrik Security Cloud MCP server under?

Rubrik Security Cloud declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/rubrik-mcp/
- Socket report: https://socket.dev/pypi/package/rubrik-mcp
- Repository: https://github.com/rubrikinc/rubrik-mcp
- Website: https://developer.rubrik.com/
- Changelog RSS feed: https://verifymcp.io/servers/rubrikinc-rubrik-mcp/rubrik-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/rubrikinc-rubrik-mcp/rubrik-mcp.json
- HTML version of this page: https://verifymcp.io/servers/rubrikinc-rubrik-mcp/rubrik-mcp