An MCP server that lets AI assistants explore Rubrik Security Cloud's GraphQL API offline and execute read (or opt-in write) operations against your RSC environment.
Discover the RSC GraphQL API – search operations by keyword, inspect full argument signatures with expanded input/enum types, and describe GraphQL types; no RSC credentials required.
Run live GraphQL queries – execute raw read-only queries against RSC with a service account.
Query Rubrik data – list workloads with protection/compliance/backup status, get recent events and failures, list clusters with health/capacity/runway, and list SLA domains with retention/archival/replication settings.
Search product help – find KB articles, product docs, and known issues for troubleshooting or "how do I" questions.
Perform gated write operations – trigger on-demand snapshots, poll jobs to completion, onboard hosts, and assign/unassign SLA domains; these are disabled by default and require enabling writes.
Manage reusable workflows – save conversation flows as named MCP tools, list saved workflows, and delete workflows.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Rubrik MCP list my workloads with their protection status and compliance state"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that connects AI assistants to the Rubrik Security Cloud GraphQL API. It's built for Rubrik admins and teams automating against Rubrik, and runs locally (on your own workstation or on an agent's server) alongside the AI assistant that calls it.
The MCP ships with a pre-built index of the entire RSC GraphQL API. The discovery tools let the AI agent explore that index — searching operations, inspecting full argument signatures, tracing input and return types — to find exactly the right operation and field shape for any request. This produces precise, well-formed GraphQL on the first try.
Discovery tools require no RSC credentials and work entirely offline. This makes them useful on their own: if you're evaluating the API, prototyping an integration, or building automation before you have production credentials, you can start immediately.
> "What operations are available for SLA management?"
> "Show me the full argument shape for the assignSla mutation."
> "Generate Python code to assign an SLA domain to a list of workload IDs."Because the agent understands both queries and mutations from the schema index, it can generate runnable Python code for any write operation — without ever connecting to RSC.
With an RSC service account, the agent can run live GraphQL queries against your environment:
List workloads with protection status, compliance state, and backup history
Retrieve recent events and failures
Trigger on-demand snapshots and poll until they complete
Register hosts and assign SLA domains
Raw GraphQL execution is read-only. If you ask for a write operation not covered by a built-in tool, the server returns the attempted mutation and the agent generates a runnable code sample. A small number of write operations are available as dedicated built-in tools: on-demand snapshots (rsc_take_on_demand_snapshot), host onboarding (rsc_onboard_host), and SLA assignment (rsc_assign_sla). These are disabled by default — set "writes_enabled": true in the gating policy to expose them. For everything else, the generated code approach gives you a runnable script with full control.
Write tools act on your Rubrik environment, and the LLM driving the MCP decides when to call them. Any model can misread instructions or be influenced by untrusted data it reads (prompt injection) and invoke a write tool you did not intend — for example an SLA change via rsc_assign_sla that leaves data unprotected. As more write tools are added, this surface grows. They are disabled by default for that reason; enabling them is an explicit choice. The durable boundary is a least-privilege, read-only service account, which cannot perform any write operation regardless of which model you use or how the agent behaves. See Service account role recommendations, and enable Quorum Authorization for destructive operations.
Discovery — no credentials required
Tool | What it does |
| Find the right query or mutation by keyword, field meaning, or type vocabulary in one call |
| Argument signature with all input/enum types expanded inline |
| Fields and values for a GraphQL type |
Execution — service account required
Tool | What it does |
| Run any raw GraphQL query (mutations generate code instead) |
| Workloads with protection status, compliance, and backup history |
| Recent events and activity, always time-scoped |
| Rubrik clusters registered in RSC, with status, version, capacity, and runway |
| SLA Domains with base frequency, retention lock, archival, and replication settings |
| Search KB articles, product docs, and known issues by keyword |
| Trigger a backup for a workload and return the job ID |
| Poll a job until completion |
| Register a physical or virtual host |
| Assign, unassign, or set do-not-protect on workloads |
Workflow management — service account required
Tool | What it does |
| Save a conversation flow as a named reusable tool |
| List all saved workflows |
| Remove a saved workflow |
After the agent has done the discovery work to answer a question, you can save that entire flow as a named MCP tool:
"Save this as a workflow so I can reuse it."
On the next restart, that tool appears alongside the built-in tools — a single call instead of multi-step schema discovery. Repeated operations use fewer tokens and respond faster. Workflow files are plain JSON you can edit, version-control, and share with your team.
Related MCP server: mcp-graphql-tools
uv (recommended), or Python 3.10 or later with pip
A Rubrik Security Cloud account with a service account (for execution tools only)
If you're using Claude Code, paste this into the chat and the agent will handle the rest:
"Add the Rubrik MCP server (PyPI package
rubrik-mcp, run it withuvx rubrik-mcp) to my Claude Code MCP configuration. My RSC service account JSON is at~/.rsc/service_account.json."
For Claude Desktop:
"Add the Rubrik MCP server (PyPI package
rubrik-mcp, run it withuvx rubrik-mcp) to my Claude Desktop config. My RSC service account JSON is at~/.rsc/service_account.json."
Using uvx (recommended): there is nothing to install separately. uvx rubrik-mcp downloads the package from PyPI into a cached, isolated environment and runs it. Use it directly as the command in your client configuration below. To pin a specific release, use rubrik-mcp@<version>, for example uvx rubrik-mcp@0.8.20260928.
Using pip:
pip install rubrik-mcpNote the full path to the installed command. You will use it in place of uvx rubrik-mcp in the client configuration:
which rubrik-mcp
# example: /Users/you/.venv/bin/rubrik-mcpFor environments that require install-time hash verification (each package checked against a known-good cryptographic hash before it is installed), a hashed requirements.txt is published in this repository for each release. Install the verified dependency set first, then the package itself:
pip install --require-hashes -r requirements.txt
pip install --no-deps rubrik-mcprequirements.txt is generated from the locked, hash-pinned dependency set (uv export); --require-hashes makes pip refuse any package whose hash does not match, and --no-deps on the second step keeps the verified set untouched. Then configure your client with the full path to rubrik-mcp, as in the pip instructions above. This path is optional; the standard install is sufficient for most users.
Claude Code:
claude mcp add rubrik -e RSC_SERVICE_ACCOUNT_FILE=/path/to/service_account.json -- uvx rubrik-mcpOptions such as -e go before --; everything after -- is the command that launches the server. For discovery-only usage, omit the -e option.
Verify it's registered:
claude mcp listClaude Desktop: edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"rubrik": {
"command": "uvx",
"args": ["rubrik-mcp"],
"env": {
"RSC_SERVICE_ACCOUNT_FILE": "/path/to/service_account.json"
}
}
}
}Desktop apps don't always inherit your shell's PATH. If Claude Desktop reports that it can't find uvx, replace "uvx" with its full path from which uvx (for example /Users/you/.local/bin/uvx).
Other MCP clients (generic stdio):
{
"name": "rubrik",
"transport": "stdio",
"command": "uvx",
"args": ["rubrik-mcp"],
"env": {
"RSC_SERVICE_ACCOUNT_FILE": "/path/to/service_account.json"
}
}If you installed with pip, set "command" to the full path of rubrik-mcp and drop "args".
Create a service account in RSC at Settings > Users and Roles > Service Accounts. Download the JSON credential file when prompted — RSC will not show the secret again.
The credential file looks like this:
{
"client_id": "client|...",
"client_secret": "...",
"access_token_uri": "https://<your-rsc-domain>/api/client_token"
}Provide it to the MCP server using one of three methods (checked in this order):
Option A — Service account JSON file (recommended)
export RSC_SERVICE_ACCOUNT_FILE=/path/to/service_account.jsonOption B — Individual environment variables
export RSC_URL=https://<your-rsc-domain>
export RSC_CLIENT_ID=client|...
export RSC_CLIENT_SECRET=...Option C — Config file at ~/.rsc/config.json
{
"client_id": "client|...",
"client_secret": "...",
"access_token_uri": "https://<your-rsc-domain>/api/client_token"
}The role you assign to the service account determines what the MCP server can access. Assign only what your workflows actually need.
For monitoring, reporting, and auditing — assign a read-only role. This covers workload listing, compliance status, event history, and backup reporting. A read-only role cannot modify SLA assignments, trigger snapshots, or change any configuration. This is the right starting point for most users.
For DevOps automation — assign a role with the specific permissions your automation requires. Common additions: SLA management permissions (to assign or modify SLA domains) and on-demand backup permissions (to trigger snapshots). Do not grant cluster admin or global admin unless the workflow explicitly requires it.
General guidance:
Create a dedicated role for the MCP service account rather than reusing an existing admin role. Name it clearly (e.g. "MCP Read-Only" or "MCP DevOps").
Configure roles at Settings > Users and Roles > Roles. Rubrik's permission model is hierarchical — scope roles to specific clusters or workload types where possible rather than granting global access.
For destructive operations (snapshot deletion, SLA policy removal, cluster configuration), enable Quorum Authorization at Settings > Security > Quorum Authorization. This requires a second authorized user to approve the operation before it executes, even when the service account has the necessary permissions.
Restrict which IPs can authenticate using the RSC IP allowlist at Settings > Security > IP Allowlist. Add only the IP or CIDR range of the machine running the MCP server.
Rotate client secrets on a schedule (monthly at minimum). Secrets do not expire by default. Use chmod 600 on any file containing a client_secret.
All API activity is recorded in RSC audit logs at Reports > Audit Logs. Review periodically.
When you find yourself asking the same question repeatedly, save it:
"Save this as a workflow so I can reuse it."
The AI calls rsc_save_workflow, which writes a JSON file to the MCP config directory's workflows/ folder — ~/.config/rubrik-mcp/workflows/ by default, or under $RUBRIK_MCP_CONFIG_DIR when set (see docs/docker.md for the containerized case). On the next restart, that workflow is registered as a named MCP tool — a single call instead of multi-step schema discovery. Repeated operations use fewer tokens and respond faster.
Workflow files are plain JSON. Open them in any editor, adjust the query, change the defaults, or share them with your team.
Community-contributed workflows (threat feed management, SLA operations, and more) are available in the rubrik-community repository. Copy any JSON file into the config directory's workflows/ folder (~/.config/rubrik-mcp/workflows/ by default, or under $RUBRIK_MCP_CONFIG_DIR) and restart your MCP client to install it.
For the full built-in tools reference, architecture diagram, the local gating policy (~/.config/rubrik-mcp/mcp-policy.json, relocatable via $RUBRIK_MCP_CONFIG_DIR), the audit log (mcp-audit.log, in the same config directory), upgrade notes for config previously kept in ~/.rubrik, and development setup, see docs/advanced.md. To run the server in a container, see docs/docker.md.
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 | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, but the description adds the non-obvious behavior an agent cannot infer: the file is removed from disk yet remains callable until restart, plus where the file lives. That is exactly the extra context the annotations don't carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and target, followed by location, side effect, Args and Returns. Every line earns its place; the Args/Returns headings are slightly heavy for a single-parameter tool but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still documents the return dict (status, name, path), the file location, and the restart-dependent lifecycle. An agent has everything needed to call and interpret this destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the lone parameter has no description in the schema, so the description carries the burden. It specifies that name is the workflow name 'as returned by rsc_list_workflows', which usefully points the agent to the authoritative source of valid values rather than inventing one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Delete) and resource (user-defined workflow), with the exact on-disk location. It is clearly distinguishable from siblings rsc_save_workflow and rsc_list_workflows, which handle creation and enumeration of the same artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives the operating context (config dir, RUBRIK_MCP_CONFIG_DIR override) and the key lifecycle caveat that the workflow still runs this session but won't load after restart, which frames when a delete is or isn't sufficient. It does not explicitly name alternative tools or state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| depth | No | ||
| operation_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuine behavioral context beyond that: recursive expansion 'up to depth levels' and the important constraint that interface fields are ONLY accessible via inline fragments. It discloses output structure, which matters since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is front-loaded and the Args/Returns structure is easy to scan. The return section is somewhat verbose, but since there is no output schema, that detail earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0% schema coverage and no output schema, the description must carry both input and output detail, and it does: it documents all three parameters and describes the return payload keys (expanded_types, return_type_fields, inline_fragments). Nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full parameter burden and does so well: it defines name format (camelCase, with example), operation_type enum values ('query' or 'mutation'), and depth semantics including its default of 2. This fully compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get an operation's signature with all input types expanded inline.' It further distinguishes itself from the sibling rsc_describe_type by noting it 'combines the operation lookup and rsc_describe_type into one call.' Clear and differentiated, though the exact GraphQL-specific scope could be tightened.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use it ('so you have everything needed to construct a correct query without guessing') and references the sibling it supersedes, rsc_describe_type. However, there is no explicit when-not guidance or clear routing rule versus calling rsc_describe_type directly — usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that by disclosing the exact return shape: name, kind, and a kind-dependent payload (fields dict for objects/inputs/interfaces, values list for enums, types list for unions). That is real information an agent needs to interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose sentence is front-loaded and the Args/Returns block is well structured and scannable. The Returns stanza is slightly verbose with its three sub-cases, but each sub-case carries distinct information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return contract, and it does so thoroughly by enumerating the possible payload shapes per type kind. Combined with read-only annotations, an agent has enough to invoke and interpret the tool; only sibling routing guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema alone does not explain the single 'name' parameter. The description compensates by labeling it 'Type name' and supplying concrete examples ("CreateGlobalSlaInput", "SlaAssignTypeEnum") that clarify the expected format and the object-vs-enum distinction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Get the definition of a GraphQL type used in RSC operations.' An agent can immediately tell this is a schema-introspection lookup rather than a search or an operation executor. It does not explicitly differentiate itself from the closely related sibling rsc_search_schema, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (call it with a type name when you need that type's definition), and the parameter example hints at RSC-specific type names. However it never states when to prefer this over rsc_search_schema or rsc_describe_operation_full, and gives no exclusions or prerequisites, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| variables | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is fully consistent while adding substantial context beyond them: the mutation_blocked error contract, three credential-source options, the single-line formatting requirement, and an explicit data-minimization caveat that raw responses are unfiltered. That is well past what the annotations carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the mutation restriction, then credentials, args, and return shape in clear blocks. Slight redundancy: the mutation_blocked result is explained at the top and again in the Returns section, and the no-newlines warning is verbose for its importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-param, no-output-schema tool this covers everything an agent needs: what it does, what it refuses, how to authenticate, how to format input, and the shape of both success and error responses, including the raw/unredacted caveat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it does: 'operation' gets format rules plus two worked GraphQL examples, and 'variables' is explained as a dict of values for parameterized operations. It loses a point only because variable-to-placeholder binding isn't illustrated with a concrete example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Execute a raw GraphQL query against the live RSC API') and immediately scopes it to queries-only, which is what separates it from the built-in write tools like rsc_take_on_demand_snapshot. An agent can identify the tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use it (mutations are unavailable via raw GraphQL) and names the alternative path ('use built-in tools (rsc_take_on_demand_snapshot, etc.) for supported write operations'). The mutation_blocked fallback behavior is also described, so the agent knows what happens on misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| cluster_type | No | ||
| name_contains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds real behavioral context beyond that: the 20/100 limit bounds, truncation semantics, and the fact that filters are applied server-side. No output schema exists, and the description explains the return payload, so disclosure is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then filters, fields, args, and returns in clearly labeled blocks; every section earns its place. The bulleted identity/status/capacity layout is somewhat verbose but justified given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when to use, every argument's semantics and allowed values, and the return envelope including truncation — more than sufficient for a 4-parameter read tool with no output schema and minimal annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden and does so: it supplies the allowed status values (Connected/Disconnected/Initializing), the cluster_type enumeration (Cloud, ExoCompute, OnPrem, Polaris, Robo, Unknown), the limit default and max, and clarifies name_contains is a server-side name filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List Rubrik CDM clusters registered in RSC') and immediately frames the scope with the inventory domains it covers, distinguishing it from siblings like rsc_get_workloads or rsc_get_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly enumerates the questions this tool answers (inventory, connection status, version, capacity, runway, sync/node health, hardware warnings), which is strong when-to-use guidance. It does not name when-not-to-use or point to an alternative sibling, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| severity | No | ||
| cluster_id | No | ||
| last_hours | No | ||
| object_name | No | ||
| workload_id | No | ||
| activity_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only profile, so the description's added value is the performance constraint ('omitting a time range makes the query very slow'), the 24-hour default window, and the failure-detail enrichment (error message, reason, remedy). That is meaningful behavior beyond the annotations, though pagination/record-cap specifics are only implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then organizes detail into Args and Returns sections with no filler sentences. It is longer than minimal, but each block (performance warning, enum lists, return-shape guidance) carries load; only mild redundancy keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with 0% schema coverage and no output schema, the description covers filters, defaults, a performance caveat, and an explicit Returns block explaining count vs returned vs truncated and advising count over len(events). Nothing an agent needs to call or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry all parameters and it does: it documents all 8, including full enum value lists for status and severity, common values for activity_type, the 'substring' semantics of object_name, and the origin of workload_id. This is exactly the compensation the schema needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get recent events and activity for workloads') and enumerates what those events contain (backup jobs, failures, anomalies). It is clearly distinguishable from siblings like rsc_get_workloads, which it references as the source of the workload FID rather than duplicating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context — 'Use this to answer "why did the backup fail for workload X"' — and instructs the agent to always pass last_hours for performance. It stops short of naming an alternative event tool or explicitly stating when not to use it, so it lands at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cluster_id | No | ||
| object_type | No | ||
| name_contains | No | ||
| is_retention_locked | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering the safety profile, the description still adds real behavioral detail: the is_retention_locked filter is applied client-side after fetching, and `count` reflects the server-side total before that filter — a footgun an agent would otherwise trip on. It also discloses the default/max limit, which the schema does not. Missing: any auth/permission or rate-limit notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then structured Identity/Objects/Coverage/Retention/Frequency/Archival/Replication and Args/Returns blocks — no filler and every section maps to caller-relevant information. It is longer than a typical description, but that length is justified by the 0% schema coverage; only the per-field result bullet list pushes slightly past what a caller needs before invoking.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by documenting the return envelope (count, returned, truncated flag) plus the contents of each sla_domains record, including the ambiguity that count is pre-client-filter. Combined with full per-argument semantics, an agent has everything needed to call this correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the entire burden and does: name_contains is labeled server-side, object_type is given concrete SlaObjectType enum examples (including K8S_OBJECT_TYPE, which the prose flags as supported), cluster_id is scoped to cluster-associated SLAs, is_retention_locked has tri-state semantics (True/False/omit), and limit states default 50 and max 200 beyond the schema's bare default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource ("List SLA Domains (protection policies) configured in RSC") and immediately defines the domain in the product's own vocabulary. It also enumerates the concrete question types it answers (counting, protecting a workload type, retention-locked SLAs, replication/archival configs), which makes it unmistakable against the generic siblings like rsc_get_workloads or rsc_get_clusters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives unusually rich context: "Use for any question about protection policies" with named filtering dimensions, then a second sentence listing alternative intents (counting, mapping workload types, retention lock, replication/archival lookup). It stops short of naming a sibling to prefer in a specific case or stating when NOT to use it, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 results. One of: "LAST_SNAPSHOT", "LAST_2_SNAPSHOTS", "LAST_3_SNAPSHOTS", "LAST_24_HOURS", "PAST_7_DAYS", "PAST_30_DAYS", "PAST_90_DAYS", "PAST_365_DAYS", "SINCE_PROTECTION". sla_id: Filter to workloads assigned to a specific SLA Domain ID. Use this to answer "list all VMs in SLA X" — pass the SLA's UUID. Matches on effective SLA (inherited or directly assigned). cluster_id: Filter to workloads managed by a specific Rubrik cluster UUID. object_fids: Filter to specific workload FIDs (list of UUIDs). Use to fetch details for a known set of workloads in a single call. object_state: Filter by lifecycle state. One of: "ACTIVE", "ARCHIVED", "RELIC", "NOT_SPECIFIED". Use "RELIC" to find decommissioned workloads that still have snapshots. org_id: Filter to workloads belonging to a specific organization UUID. is_local: True to return only local workloads; False for remote/replicated only. Omit to return both. excluded_object_types: List of workload types to exclude. Cannot be combined with object_type. sort_by: Field to sort by, e.g. "MissedSnapshots", "Name", "LastSnapshot", "ComplianceStatus", "SlaDomainName". sort_order: "ASC" or "DESC". limit: Maximum number of results to return. Omit for all results (bounded by the server-side record cap).
Returns:
A dict with:
- count: the true total matching the filter (the connection's count).
- returned: how many workloads are in this response.
- truncated: True when returned < count (more exist than returned,
because of limit or the record cap). Report count for
"how many" questions, not len(workloads).
- workloads: the list of workload records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| org_id | No | ||
| sla_id | No | ||
| sort_by | No | ||
| is_local | No | ||
| cluster_id | No | ||
| sort_order | No | ||
| object_fids | No | ||
| object_type | No | ||
| search_term | No | ||
| object_state | No | ||
| sla_time_range | No | ||
| compliance_status | No | ||
| protection_status | No | ||
| excluded_object_types | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read, and the description goes well beyond that: it discloses the default sla_time_range behavior (entire protection lifetime, which "often overstates violations"), the server-side record cap when limit is omitted, and the exact semantics of count vs returned vs truncated. It also explains the subtle EMPTY vs NULL compliance distinction to prevent misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded and segmented into purpose / per-result fields / Args / Returns, so an agent can scan it. It is long, and the extended NULL-vs-EMPTY digression and repeated enum explanations push slightly past what is strictly needed, but for a 15-param tool it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 15 undocumented params, the description must supply both filter semantics and return-shape semantics, and it does: it documents the response dict keys and warns to report count rather than len(workloads). Nothing an agent needs to call or interpret this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 15 params, so the description carries the full burden and does: it lists enum values for protection_status, sla_time_range, object_state, sort_order, defines each compliance_status state, and states the mutual exclusion between object_type and excluded_object_types. This is far richer than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("List workloads") and then enumerates exactly what each record contains (identity, SLA, compliance, backup history, usage, location). No sibling tool (clusters, SLA domains, events) covers workloads, so an agent can place this unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete when-to-use context for several params: sla_id is for "list all VMs in SLA X", object_fids is for fetching a known set in one call, object_state RELIC finds decommissioned workloads, and sla_time_range advises preferring a shorter window for actionable results. It stops short of naming alternative sibling tools or explicit when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful context beyond that: the config directory resolution rule (~/.config/rubrik-mcp/workflows/ or $RUBRIK_MCP_CONFIG_DIR) and what is returned per workflow. It stops short of describing empty-directory or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed by the resolution rule and return shape. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be enumerated, yet the description still previews the fields (name, description, step count, path). For a zero-param read-only listing tool, nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List all user-defined workflows') plus the exact scope ('workflows/ folder in the MCP config dir'). No sibling in the set performs this listing function (save/delete_workflow are mutations), so the agent can distinguish it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool's nature — it enumerates workflows so the agent can then pick one for save/delete/describe. However, no explicit when-to-use, when-not, or alternative routing is provided, so it remains at the minimum-viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| spec | No | ||
| steps | No | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it names the exact write location (~/.config/rubrik-mcp/workflows/, overridable via $RUBRIK_MCP_CONFIG_DIR), states the workflow is registered immediately, that it loads on next server start, and that the file path comes back in the response. It also discloses the execution split — RSC steps run server-side while non-RSC steps are returned as next_steps — which is critical behavioral context an agent cannot infer. The destructiveHint=true annotation is consistent with a tool that writes files and registers a new callable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and trigger, then the args. The embedded spec example is long but earns its place by making the step/interpolation format unambiguous. Slightly verbose in the Returns note, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly supplies the return shape (status, name, path, restart note) and explains the persistence/restart lifecycle. Combined with the arg documentation and the step-format example, an agent has everything needed to construct and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden, and it does: it defines all four parameters, gives the naming constraint ('valid Python identifier, e.g. rsc_get_aws_failures'), and shows a full spec example with interpolation syntax. The only gap is a mild tension with the schema — it says to provide 'either spec or steps + other fields,' yet name and description are unconditionally required, and the description does not resolve that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb+resource+outcome: 'Save a multi-step workflow as a named, callable MCP tool.' It is clearly distinguishable from siblings like rsc_list_workflows and rsc_delete_workflow, which operate on an existing workflow store rather than creating one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this after completing a workflow in conversation to persist it for future use' gives a concrete trigger condition, and the description explains the spec-vs-steps alternative for constructing the call. It stops short of stating when NOT to use it (e.g., updating or overwriting an existing workflow) or which sibling to prefer for editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm it is a safe read (readOnlyHint=true, destructiveHint=false). The description adds important behavioral context beyond the annotations: that KB articles reflect current product state, that results may be truncated, and that links can be null. The main minor gap is no mention of pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with purpose and usage guidelines, then structured into Args and Returns sections. Every sentence is useful, though the response is slightly longer than strictly necessary with its formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description appropriately explains the return structure, including count/returned/truncated/results and the null-link caveat. It is complete enough for an agent to call and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It fully documents all three parameters, including examples and the enum-like values for source and the default for limit, compensating completely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search Rubrik KB articles, product documentation, and known issues.' This clearly distinguishes it from API/schema exploration siblings like rsc_search_schema or rsc_describe_type, which serve a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use triggers: an event/workload has an error, a troubleshooting/how-do-I question, or an error code is present. It also gives a strong directive: 'Always call this before answering from memory,' which is a clear usage policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| search | Yes | ||
| operation_type | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing that three indexes (operation, field, type) are queried, that results are deduplicated and merged, and that duplicates surface once with the highest score — behavior an agent cannot get from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-line purpose, then progressively more detail in the index and Args/Returns sections. The index bullets carry real information about matching semantics rather than filler, so the length is earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly supplies the return shape (operations list with name, type, description, return_type, score, source, plus the echoed search string). Combined with full parameter documentation and the usage trigger, an agent has everything needed to call and interpret it; only the absence of a stated result limit/pagination keeps it from being exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load, and it does: 'search' is constrained to non-empty natural language with the caveat to use descriptive terms rather than operation names, and 'operation_type' is enumerated as query/mutation/all with the default stated. Both parameters are fully specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource (the full RSC GraphQL schema) with clear scope ('to find relevant operations'). The line 'Use this whenever you need to find an operation and don't already know its name' implicitly separates it from naming-based siblings like rsc_describe_operation_full.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition ('when you need to find an operation and don't already know its name') and routes read-only vs write intent via operation_type ('query' for read-only intent, 'mutation' for write intent). It stops short of naming the alternative tools to use instead when the operation name is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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): /app/.venv/bin/rubrik-job-monitor --job-id --object-type [--cluster-id ] Monitor(command): /app/.venv/bin/rubrik-job-monitor --job-id --object-type [--cluster-id ]
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 | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| timeout | No | ||
| cluster_id | No | ||
| object_type | Yes | ||
| poll_interval | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description goes further by disclosing blocking behavior, the timeout default of 300s, poll interval defaults, and the fact that a timeout can return a timed_out result rather than failing. It also enumerates the status value vocabularies per backend. It does not cover rate limits or what happens if the job never completes, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and required-argument retrieval are front-loaded, and the format is clearly sectioned. However, the embedded Bash/Monitor command block for the monitoring alternative is lengthy relative to the tool's own contract, adding tangential detail that dilutes an otherwise tight definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by describing the return structure (status, progress, done, raw, optional timed_out) and mapping status value sets to each backend. Combined with the argument sourcing guidance, an agent has everything needed to invoke and interpret the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden and does so for all five parameters. It explains that job_id means different things per workload (AsyncRequestStatus id vs taskchainUuid), that object_type selects the status query, that cluster_id is required only for CDM, and gives units/defaults for timeout and poll_interval.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb and resource with its full scope: 'Poll an RSC job until it completes and return the final status.' It also distinguishes itself from async siblings by stating it handles all job types automatically based on objectType.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit instructions for obtaining job_id and cluster_id, split by workload class (CDM vs cloud-native), and names a concrete alternative path for non-blocking use (rubrik-job-monitor via Bash/Monitor). An agent knows exactly when to use this tool and when to use the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0rsc_delete_workflowrsc_describe_operation_fullrsc_describe_typersc_execute_operationrsc_get_clustersrsc_get_eventsrsc_get_sla_domainsrsc_get_workloadsrsc_list_workflowsrsc_save_workflowrsc_search_helprsc_search_schemarsc_wait_for_jobScored across 13 tools
The three schema-introspection tools (rsc_search_schema, rsc_describe_type, rsc_describe_operation_full) are closely related but their descriptions clearly delineate search vs. type lookup vs. full operation expansion. The data-fetching tools each target a distinct resource (workloads, events, clusters, SLA domains), and workflow CRUD is unambiguous.
All tools share a uniform rsc_ prefix followed by a consistent snake_case verb_noun pattern (get_workloads, list_workflows, delete_workflow, search_schema, describe_type, wait_for_job). No mixed conventions or stray casing.
13 tools is well within the ideal 3-15 range, with each tool earning its place across introspection, read operations, job polling, and workflow management. No redundancy that would justify trimming.
Read coverage is solid (workloads, events, clusters, SLAs, help) and raw queries via rsc_execute_operation fill gaps, but mutations are explicitly blocked and there are no built-in write/recovery tools despite descriptions referencing rsc_take_on_demand_snapshot and similar 'built-in tools' that are absent from the surface. This leaves a notable gap for any write/protection workflow.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Connect your AI assistants to Keboola and expose your data, transformations, SQL queries, ...
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
