Skip to main content
Glama

Control Plane

by io.cpln

Delete a Resource

delete_resource
Destructive

Delete one Control Plane resource by kind + name — the single delete tool for every deletable kind. Secrets are not deletable here — their lifecycle is managed by the user. Deletes on the call (your client confirms the write first). Before calling, read the resource and tell the user what the deletion removes and which dependents break, and proceed only on their explicit approval. Deletion is permanent. Never invent a name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gvcNoGVC slug — REQUIRED only for GVC-scoped kinds (workload, identity, volumeset); ignored otherwise.
orgYesOrganization 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.
kindYesResource kind to delete. One of: workload, identity, volumeset, gvc, policy, group, domain, cloudaccount, agent, ipset, mk8s, serviceaccount, image, user.
nameYesName of the resource to delete. Read the resource and present what the deletion removes and breaks, then call only on the user's explicit approval. Never invent a name. Most kinds use lowercase kebab-case names; exceptions: domain = the full hostname ("app.example.com"), image = NAME or NAME:TAG ("my-app:v1.2").

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether the call succeeded.
dataNoThe full machine-readable result — list rows, the resource object, query results. Read THIS, not just the summary.
summaryYesOne-line summary of the result.
nextStepsNoRecommended follow-up actions for this task, in order.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / kind / description
      Previous value: -"Resource kind to delete. One of: workload, identity, volumeset, gvc, secret, policy, group, domain, cloudaccount, agent, ipset, mk8s, serviceaccount, image, user."New value: +"Resource kind to delete. One of: workload, identity, volumeset, gvc, policy, group, domain, cloudaccount, agent, ipset, mk8s, serviceaccount, image, user."
    • changedInput schema / properties / kind / enum
      Previous value: -[
-  "workload",
-  "identity",
-  "volumeset",
-  "gvc",
-  "secret",
-  "policy",
-  "group",
-  "domain",
-  "cloudaccount",
-  "agent",
-  "ipset",
-  "mk8s",
-  "serviceaccount",
-  "image",
-  "user"
-]New value: +[
+  "workload",
+  "identity",
+  "volumeset",
+  "gvc",
+  "policy",
+  "group",
+  "domain",
+  "cloudaccount",
+  "agent",
+  "ipset",
+  "mk8s",
+  "serviceaccount",
+  "image",
+  "user"
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description adds critical behavioral context: deletion is permanent, the call triggers deletion immediately ('your client confirms the write first'), and it mandates a user-approval workflow before invoking. It also clarifies that secrets are managed elsewhere, preventing misuse. These details significantly enhance the agent's understanding of consequences.

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 yet information-dense. Every sentence contributes value: the core action, the exclusivity, the secrets exception, the immediate deletion behavior, the required pre-call procedure, permanence, and name accuracy. There is no redundant or promotional language.

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?

For a destructive tool, the description is exceptionally complete. It covers the action, scope, exclusions, procedural requirements, and permanence. The output schema exists, so not describing return values is acceptable. The combination of annotations, schema, and description leaves little room for ambiguity in a high-stakes delete operation.

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 input schema provides 100% coverage with detailed descriptions for all parameters, including patterns and conditional requirements (e.g., gvc only for GVC-scoped kinds). The description reinforces the importance of 'name' with 'Never invent a name' but does not add substantial new semantics beyond the schema. Therefore, the baseline score of 3 applies.

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 clearly states the tool's function: 'Delete one Control Plane resource by `kind` + `name`'. It also positions it as the single delete tool for every deletable kind, distinguishing it from sibling tools that handle specific removal operations like remove_domain_port or uninstall_template. The exclusion of secrets further sharpens its scope.

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?

The description explicitly says when to use this tool: for any deletable Control Plane resource, and when not to: secrets are not deletable here. It provides a clear pre-call procedure: read the resource, inform the user of impacts, and proceed only on explicit approval. The 'Never invent a name' instruction adds practical safety guidance.

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

All Control Plane toolsInspect
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).

Resources