Rafay MCP Server Phase 2: From Visibility to Lifecycle Management¶
In June we introduced the Rafay MCP Server, giving MCP-compatible AI clients secure, RBAC-aware, read-only access to your Rafay platform resources. That first release was about visibility and troubleshooting: listing clusters, inspecting blueprint versions, and answering operational questions in natural language.
Phase 2 takes the next step. Coming in the upcoming v4.3 release, the Rafay MCP Server can now create, update, delete, and publish a set of platform resources, letting authorized users move from asking questions about their environment to acting on it, without leaving their AI client and without stepping outside Rafay's governance controls. For the full list of changes, see the v4.3 release notes.
What's New in Phase 2¶
Write operations for platform resources¶
The MCP Server now supports write operations on the following resources:
| Resource | Supported operations |
|---|---|
| Add-ons | Create, update, delete |
| Workloads | Create, update, delete, publish, unpublish |
| Blueprints | Create, update, delete, publish onto a cluster |
Every operation flows through the same Rafay APIs, the same API key, and the same RBAC model you already use. The AI client can only change what the key is permitted to change.
New tools¶
Phase 1 shipped with rafay_get, rafay_list, rafay_describe, and rafay_execute. Phase 2 adds five new tools:
| Tool | What it does |
|---|---|
rafay_apply |
Create or update a resource from a spec |
rafay_delete |
Delete a resource |
rafay_schema |
Return the schema for a resource type, so the AI client can build a valid spec |
rafay_examples |
Return example specs for a resource type |
rafay_terraform_docs |
Return Terraform provider documentation for a resource |
The rafay_schema and rafay_examples tools are the quiet workhorses here. Instead of asking the AI to recall the shape of a Rafay resource from memory, the client can fetch the exact schema and a working example on demand, then generate a spec that rafay_apply will accept. rafay_terraform_docs extends the same idea to teams managing Rafay through Terraform.
kubectl write commands¶
In Phase 1 rafay_execute was limited to read-only kubectl commands. With write access enabled, rafay_execute now allows write kubectl commands as well, subject to the same RBAC enforcement.
Secure by Design: Write Access Is Opt-In¶
Extending an AI client's reach from reading to writing raises the stakes, so Phase 2 puts the decision in the hands of your Organization Admin.
- Read-only by default. Every MCP Server deployment starts in read-only mode. Nothing changes for existing users until an admin chooses otherwise.
- Admin-controlled toggle. An Organization Admin enables write access under System > Settings > MCP Server in the Rafay console. Only an Organization Admin can enable or disable it.
- Fail closed. When write access is disabled, write tools remain visible but any write operation returns an error rather than silently succeeding.
- RBAC still applies. Enabling write access does not grant new permissions. Users can only create, update, or delete what their Rafay role already allows.
- Fully audited. Every operation performed through the MCP client is recorded in the Rafay audit logs, so you retain a complete, attributable trail of what was changed and by whom.
Combine this with the guidance from Phase 1: use least-privilege API keys, store them securely, and rotate them per your organization's policy.
Get Started¶
If you are already running the Rafay MCP Server, update to the latest version to pick up the new tools. Then:
- Ask an Organization Admin to enable Allow write access under System > Settings > MCP Server.
- Confirm the API key used by your MCP client has the Rafay role needed for the resources you want to manage.
- Open your MCP client and start with a
rafay_schemaorrafay_examplescall to see what a resource spec looks like.
For the full list of supported resources, tools, and operations, see the Rafay MCP Server documentation.
Conclusion¶
Phase 1 gave your AI clients a trusted window into your Rafay environment. Phase 2 gives them a governed set of hands. Workloads, add-ons, and blueprints can now be created, updated, deleted, and published through natural language, with write access controlled by your Organization Admin and every action bound by the RBAC you already rely on.
We will continue to expand the set of resources that support write operations in upcoming releases.