Control Plane

Get Resource Schema & API Endpoints

get_resource_schema

Read-onlyIdempotent

Return the exact object schema and REST API endpoints for a Control Plane resource kind, so you can author an accurate manifest for cpln apply or call the API directly. Call it before writing a cpln apply manifest, a CI/CD spec, or a REST body; never guess field names. Pick a kind and pass org (and gvc for workload/identity/volumeset). Large schemas come back as a shallow map with deep sections collapsed to {"_expand":""} stubs; pass path (e.g. "spec.containers") to expand a section on demand. Server-managed fields (id/status/version/etc.) are already removed; name and kind are required at create.

Input Schema

TableJSON Schema

Name	Required	Description
`gvc`	No	GVC slug. REQUIRED only for GVC-scoped kinds (workload, identity, volumeset); ignored for org-scoped kinds.
`org`	No	Organization slug.
`kind`	Yes	The Control Plane resource kind to describe. Returns its apply-ready object schema plus the concrete REST endpoints. workload, identity, and volumeset are GVC-scoped (require `gvc`); all others are org-scoped.
`path`	No	Dot-path into the schema to expand in full, e.g. "spec.containers" or "spec.defaultOptions.autoscaling". Omit for the top-level overview. Deeply nested objects come back as {"_expand":"<path>"} stubs — call this tool again with `path` set to that value to see that section.
`maxDepth`	No	Override how many object levels to expand from the path root. Omit for the default (small schemas return in full; large ones return a shallow map you can drill into). Raise it to pull more in one call.

Output Schema

TableJSON 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.

Changed17 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 / gvc / maxLength
```
Removed value: -63
```
removedInput schema / properties / gvc / minLength
```
Removed value: -1
```

removedInput schema / properties / gvc / pattern

Removed value: -"^[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?$"

changedInput schema / properties / org / description

Previous value: -"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."New value: +"Organization slug."

removedInput schema / properties / org / maxLength
```
Removed value: -63
```
removedInput schema / properties / org / minLength
```
Removed value: -1
```

removedInput schema / properties / org / pattern

Removed value: -"^[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?$"

changedInput schema / required

Previous value: -[
-  "kind",
-  "org"
-]New value: +[
+  "kind"
+]

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."
```

First observedJun 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses non-obvious behaviors: large schemas return a shallow map with deep sections collapsed to {"_expand":"<path>"} stubs, `path` drills in on demand, server-managed fields (id/status/version) are stripped, and `name`/`kind` are required at create. This is rich operational context the annotations cannot convey.

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?

Front-loads purpose, then usage trigger, then the expansion mechanic, then the field-stripping caveat. Dense but every sentence carries distinct operational value with concrete examples.

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 needn't be documented, yet the description still clarifies the expansion stub behavior. Combined with the usage trigger and gvc scoping rule, nothing needed to call it correctly is missing.

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 a 3, but the description adds cross-parameter meaning: it explains that `gvc` is needed only for workload/identity/volumeset and the path/maxDepth expansion contract, going beyond the per-field text.

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?

States a precise verb+resource: 'Return the exact object schema and REST API endpoints for a Control Plane resource kind'. It also names the downstream goal (authoring a manifest for `cpln apply` or calling the API directly), which separates it from lookups like get_resource and list_resources.

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

Usage Guidelines5/5

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

Explicitly instructs 'Call it before writing a `cpln apply` manifest, a CI/CD spec, or a REST body; never guess field names.' It states the triggering condition and the anti-pattern to avoid, leaving no inference to the agent.

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.