Control Plane

Create an Identity

create_identity

Create a new identity in a GVC. Provider blocks can provision real resources in the connected cloud account, including AWS IAM roles, GCP service accounts, and Azure managed identities. Optionally seed networkResources (agent-based) and nativeNetworkResources (PrivateLink / PSC). Identities are assigned to workloads via spec.identityLink. Recommended reading before first use: get_cpln_skill("access-control") — the runbook for this tool family (read once per session).

Input Schema

TableJSON Schema

Name	Required	Description
`aws`	No	AWS cloud-identity block. Binds the identity to an AWS cloud account so workloads can assume the role.
`gcp`	No	GCP cloud-identity block. Binds the identity to a GCP service account / bindings on cloud resources.
`gvc`	Yes	GVC slug (lowercase kebab-case). Use the GVC the user named; otherwise discover with list_resources (kind="gvc") and let them choose — never guess (a wrong GVC targets the wrong environment).
`ngs`	No	NGS cloud-identity block. Binds the identity to a NATS account for pub/sub permissions.
`org`	Yes	Organization slug (lowercase kebab-case). NEVER guess — if the user has not named one, ask. On org-not-found, stop and ask; do not retry variants.
`name`	Yes	Resource name (lowercase kebab-case, starts with a letter, 2-64 chars). Names are IMMUTABLE — renaming = delete + recreate (loses URL, DNS, policy links).
`tags`	No	Optional tags for the identity.
`azure`	No	Azure cloud-identity block. Binds the identity to an Azure managed identity with role assignments.
`description`	No	Identity description.
`spicedbAccess`	No	Grant access to SpiceDB clusters (max 5).
`memcacheAccess`	No	Grant access to memcache clusters (max 5).
`networkResources`	No	Agent-based network resources (cloud wormhole). Max 50 (nativeNetworkResources has its own separate limit); names/FQDNs share one namespace across both arrays.
`nativeNetworkResources`	No	Optional cloud-native network resources (AWS PrivateLink, GCP PSC). Each item requires name, ports, and exactly one provider block. Max 50 (networkResources has its own separate limit); names/FQDNs share one namespace across both arrays.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the call succeeded.
`data`	No	The full machine-readable result — list rows, the resource object, query results. Read THIS, not just the summary.
`summary`	Yes	One-line summary of the result.
`nextSteps`	No	Recommended follow-up actions for this task, in order.

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses a significant side effect beyond the annotations: provider blocks can provision real resources in the connected cloud account (AWS IAM roles, GCP service accounts, Azure managed identities). It also adds useful behavioral context about optional networkResources and nativeNetworkResources, complementing the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, with the core action first followed by a few high-value sentences about provider behavior, network resources, assignment, and prerequisite reading. Every sentence adds useful context with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 13 parameters, nested objects, and cloud-provider side effects, the description supplies the essential conceptual framing and points to an access-control runbook. It is complete enough for an agent to understand what creating an identity involves, though it does not spend time contrasting the update/delete lifecycle.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of parameters with rich descriptions, so the baseline applies. The description adds high-level conceptual value — real cloud resource provisioning and the identity-to-workload link — but does not add per-parameter detail beyond the well-documented input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and scope: "Create a new identity in a GVC." It clearly distinguishes this from update_identity and other sibling tools, and reinforces purpose by explaining that identities are later assigned to workloads via spec.identityLink.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Guidance is implied rather than explicit: the description mentions provider-backed resources, optional network resources, and a recommended access-control runbook to read before first use. However, it does not name alternatives such as update_identity/delete_resource or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Control Plane tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Every tool targets a distinct resource/action pair (e.g., get_resource vs get_resource_schema, list_deployments vs list_workload_replicas) and descriptions clearly differentiate purposes. No two tools appear to do the same thing.

Naming Consistency5/5

All tools follow a verb_noun snake_case pattern (create_gvc, update_workload, list_resources, query_metrics) with consistent verbs. The few imperative verbs (browse, build, mount) still maintain the same verb-first structure.

Tool Count1/5

With 55 tools, this server far exceeds the typical well-scoped 3-15 tool range. While each tool appears purposeful, the sheer number creates selection overhead and falls into the extreme 50+ category on the rubric.

Completeness4/5

The surface covers nearly the full Control Plane lifecycle: CRUD for GVC, workload, identity, policy, volumeset, and domain, plus observability, templates, image builds, and Terraform. Minor gaps include referenced but missing configure_workload_* tools and no secret creation/deletion (by design).