Control Plane

Export to Terraform

export_terraform

Read-onlyIdempotent

Generate Terraform (HCL) for EXISTING Control Plane resources from a self link (resource): one resource (/org/acme/gvc/prod/workload/api) or bulk by path depth (/org/acme exports the whole org, /org/acme/gvc/prod/workload every workload in a GVC). Or convert a manifest (YAML or JSON) with its org, and gvc for a GVC-scoped kind: it is dry-run validated against the API first (nothing is created), and a validation failure returns the error instead of HCL. Set generateImports to get ready-to-run terraform import commands for adopting the resources into Terraform state, and includeDependencies to pull in referenced resources. Secrets are never exported or converted: a ref, manifest, or dependency closure that includes one is refused. An unsupported kind is rejected with the supported list.

Input Schema

Name	Required	Description
`gvc`	No	The `manifest`'s GVC when its kind is GVC-scoped (workload, identity, volumeset). With `resource`, it must match the self link.
`org`	No	The `manifest`'s org. With `resource`, it must match the self link, and is required when several orgs are granted.
`manifest`	No	Instead of `resource`: one resource manifest to convert, YAML or JSON, with `kind` and `name`.
`resource`	No	Self link of an existing resource, e.g. `/org/acme/gvc/prod/workload/api` (a full `https://api.cpln.io/org/...` URL is also accepted). Use a shorter path for a bulk export: `/org/acme` (whole org) or `/org/acme/gvc/prod/workload` (all workloads in a GVC).
`generateImports`	No	Also return the matching `terraform import` commands, one per resource with the import IDs prefilled. Run them after `terraform init` and before the first `terraform apply` so the existing resources are adopted into state instead of re-created.
`includeDependencies`	No	With `resource`: also export referenced/dependent resources so the generated HCL is self-contained.

Output Schema

Name	Required	Description
`ok`	Yes
`data`	No	The full result. Read this, not only the summary.
`details`	No
`summary`	Yes
`nextSteps`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 22, 2026

addedInput schema / properties / gvc

Added value: +{
+  "description": "The `manifest`'s GVC when its kind is GVC-scoped (workload, identity, volumeset). With `resource`, it must match the self link.",
+  "type": "string"
+}

changedInput schema / properties / includeDependencies / description

Previous value: -"Also export referenced/dependent resources so the generated HCL is self-contained."New value: +"With `resource`: also export referenced/dependent resources so the generated HCL is self-contained."

addedInput schema / properties / manifest

Added value: +{
+  "description": "Instead of `resource`: one resource manifest to convert, YAML or JSON, with `kind` and `name`.",
+  "type": "string"
+}

addedInput schema / properties / org

Added value: +{
+  "description": "The `manifest`'s org. With `resource`, it must match the self link, and is required when several orgs are granted.",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "resource"
-]
```

Changed11 schema fields changedSep 30, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / resource / maxLength
```
Removed value: -512
```
removedInput schema / properties / resource / minLength
```
Removed value: -3
```

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / properties / data / description

Previous value: -"The full machine-readable result — list rows, the resource object, query results. Read THIS, not just the summary."New value: +"The full result. Read this, not only the summary."

addedOutput schema / properties / details
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / nextSteps / description

Removed value: -"Recommended follow-up actions for this task, in order."

removedOutput schema / properties / ok / description
```
Removed value: -"Whether the call succeeded."
```
removedOutput schema / properties / summary / description
```
Removed value: -"One-line summary of the result."
```

Changed1 schema field changedAug 14, 2026

removedInput schema / properties / includeSecretValues

Removed value: -{
-  "default": false,
-  "description": "Exported secrets embed their REVEALED PLAINTEXT values in the HCL (the exporter follows the reveal link). false (default): refs that directly target secrets are refused, and an export that pulls secrets in via includeDependencies/org-root is refused too (re-run with this flag to allow it). true: values pass through and the result is labeled sensitive — set ONLY after the user explicitly approves.",
-  "type": "boolean"
-}

First observedJun 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantive context beyond them: manifest conversion is dry-run validated against the API first (nothing is created), validation failures return the error instead of HCL, secrets are never exported or converted and a closure containing one is refused, and unsupported kinds are rejected with the supported list. These are exactly the failure-mode and side-effect details an agent needs.

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

Conciseness4/5

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

Front-loaded with the core verb and resource, and every sentence carries real information (modes, dry-run, secrets exclusion, unsupported kinds). It is a single dense paragraph with nested parentheticals and example paths, which makes it slightly harder to scan than a short bulleted layout would be.

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

Completeness5/5

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 no explanation, and the 100% schema coverage covers the inputs. For a read-only export tool the description supplies the remaining essentials: mode selection, dry-run/validation behavior, secret refusal, and rejection of unsupported kinds.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds the one thing the schema does not declare: that `resource` and `manifest` are mutually exclusive alternatives (no required params are marked), and that `gvc` only matters for GVC-scoped manifest kinds while `org` is required when several orgs are granted. That clarifies overall parameter interplay rather than merely restating field docs.

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 names a specific verb and artifact ("Generate Terraform (HCL)") and the exact resource scope (EXISTING Control Plane resources), then enumerates the two distinct input modes: a self link or a manifest. No sibling tool in the list generates Terraform/HCL, and the description makes that unique purpose unmistakable.

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

Usage Guidelines4/5

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

It clearly explains which parameter selects which behavior: `resource` for existing resources (with bulk semantics by path depth, e.g. `/org/acme` exports the whole org), or `manifest` plus `org`/`gvc` for conversion. It also states when to set `generateImports` (after `terraform init`, before first `apply`) and `includeDependencies`. It doesn't name an alternative sibling tool to use instead, but no sibling competes for this job.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.