Rubrik Security Cloud
PYPI · RUBRIK-MCP · SCANNED OCT 4
Connect AI assistants to the Rubrik Security Cloud GraphQL API to discover, query, and automate.
Available components
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. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
- 1 of 38 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency97
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to rubrikinc/rubrik-mcp). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 1 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability63
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management13
- Stability observed for 4 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (8% of tools); any adoption earns full credit.Pass
Tool Safety88
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 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. See how to fix → Partial
- An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
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.
pypi · rubrik-mcp
claude mcp add rubrikinc-rubrik-mcp -- uvx rubrik-mcp
{
"mcpServers": {
"rubrikinc-rubrik-mcp": {
"command": "uvx",
"args": [
"rubrik-mcp"
]
}
}
} {
"servers": {
"rubrikinc-rubrik-mcp": {
"command": "uvx",
"args": [
"rubrik-mcp"
]
}
}
} codex mcp add rubrikinc-rubrik-mcp -- uvx rubrik-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"rubrikinc-rubrik-mcp": {
"type": "local",
"command": [
"uvx",
"rubrik-mcp"
],
"enabled": true
}
}
} openclaw mcp add rubrikinc-rubrik-mcp --command uvx --arg rubrik-mcp
mcp_servers:
rubrikinc-rubrik-mcp:
command: "uvx"
args: ["rubrik-mcp"] {
"McpServers": {
"rubrikinc-rubrik-mcp": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"rubrik-mcp"
]
}
}
} assistant mcp add rubrikinc-rubrik-mcp -t stdio -c uvx -a rubrik-mcp
{
"mcpServers": {
"rubrikinc-rubrik-mcp": {
"command": "uvx",
"args": [
"rubrik-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Oct 26 +16
- Malware scan: unverified → pass ▲ security
- 3 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- 2 Oct 26 +16
- Malware scan: unverified → pass ▲ security
- Stability: unverified → 0.07 ▲ functional
- Package version: 0.8.20260914 → 0.8.20260928 functional
- 30 Sept 26 61
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 4 Oct 2026 · Analysed pypi/rubrik-mcp@0.8.20260928
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | pypi |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | rubrikinc/rubrik-mcp |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/rubrikinc/rubrik-mcp/.github/workflows/publish.yml@refs/tags/v0.8.20260928 |
| Rekor log index | 3060441281 |
| Predicate type | PyPI publish attestation https://docs.pypi.org/attestations/publish/v1 |
| Subject digest | sha256:32f3f4eb77e169b1e858f841d5f5184591c5d080ead1b59d064f73f94f85c600 |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 38 packages
| Packages resolved | 38 |
|---|---|
| Stale | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
rsc_delete_workflow ~122
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.
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | – |
No output schema declared.
No examples provided.
rsc_describe_operation_full ~266
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.
| Name | Type | Req | Description |
|---|---|---|---|
| depth | integer | – | – |
| name | string | yes | – |
| operation_type | string | yes | – |
No output schema declared.
No examples provided.
rsc_describe_type ~108
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
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | – |
No output schema declared.
No examples provided.
rsc_execute_operation ~372
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.
| Name | Type | Req | Description |
|---|---|---|---|
| operation | string | yes | – |
| variables | – | – | – |
No output schema declared.
No examples provided.
rsc_get_clusters ~325
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cluster_type | – | – | – |
| limit | integer | – | – |
| name_contains | – | – | – |
| status | – | – | – |
No output schema declared.
No examples provided.
rsc_get_events ~420
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)`.
| Name | Type | Req | Description |
|---|---|---|---|
| activity_type | – | – | – |
| cluster_id | – | – | – |
| last_hours | number | – | – |
| limit | integer | – | – |
| object_name | – | – | – |
| severity | – | – | – |
| status | – | – | – |
| workload_id | – | – | – |
No output schema declared.
No examples provided.
rsc_get_sla_domains ~464
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cluster_id | – | – | – |
| is_retention_locked | – | – | – |
| limit | integer | – | – |
| name_contains | – | – | – |
| object_type | – | – | – |
No output schema declared.
No examples provided.
rsc_get_workloads ~995
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…
| Name | Type | Req | Description |
|---|---|---|---|
| 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 | – | – | – |
No output schema declared.
No examples provided.
rsc_list_workflows ~75
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
rsc_save_workflow ~463
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.
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | yes | – |
| name | string | yes | – |
| spec | – | – | – |
| steps | – | – | – |
No output schema declared.
No examples provided.
rsc_search_help ~287
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.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | – |
| query | string | yes | – |
| source | – | – | – |
No output schema declared.
No examples provided.
rsc_search_schema ~303
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
| Name | Type | Req | Description |
|---|---|---|---|
| operation_type | string | – | – |
| search | string | yes | – |
No output schema declared.
No examples provided.
rsc_wait_for_job ~464
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.
| Name | Type | Req | Description |
|---|---|---|---|
| cluster_id | – | – | – |
| job_id | string | yes | – |
| object_type | string | yes | – |
| poll_interval | integer | – | – |
| timeout | integer | – | – |
No output schema declared.
No examples provided.
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.