mcp

Release a custom domain (needs approval)

release_domain

DestructiveIdempotent

Removes a custom domain from this account: a verified domain is no longer verified for it (using it again needs a new TXT check), and a pending claim is cancelled. The first call releases nothing: it shows the domain for the user to approve; call again with confirm:true only after their yes. The second call reports the platform's answer: released, or refused. A refusal because public names still use the domain (DOMAIN_IN_USE) lists those names, each with its id: remove each with delete_dns_entry (it asks for the user's yes first), then call this again. Releasing a domain deletes no deployment, instance or cluster.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "release_domain"
  }
}

Input Schema

Name	Required	Description	Default
`domain`	Yes	The custom domain to release, as list_domains shows it.
`confirm`	No	Set true ONLY after the user has explicitly approved releasing this domain (see the confirmation the first call returns). Do NOT set it yourself.

Output Schema

Name	Required	Description	Default
`mode`	No
`next`	No
`claim`	No
`error`	No
`names`	No
`domain`	No
`status`	No
`details`	No
`matches`	No
`message`	No
`recovery`	No
`released`	No
`validation`	No
`account_notices`	No
`needs_confirmation`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 5, 2026

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

addedOutput schema / properties / error / anyOf

Added value: +[
+  {
+    "anyOf": [
+      {
+        "not": {}
+      },
+      {
+        "type": "boolean"
+      }
+    ]
+  },
+  {
+    "anyOf": [
+      {
+        "not": {}
+      },
+      {
+        "type": "boolean"
+      }
+    ]
+  }
+]

removedOutput schema / properties / error / type
```
Removed value: -"boolean"
```
addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / recovery
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / status
```
Added value: +{}
```

addedOutput schema / properties / validation / anyOf

Added value: +[
+  {
+    "anyOf": [
+      {
+        "not": {}
+      },
+      {}
+    ]
+  },
+  {
+    "anyOf": [
+      {
+        "not": {}
+      },
+      {}
+    ]
+  }
+]

Changed1 schema field changedOct 31, 2026

addedOutput schema / properties / account_notices

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "dismissible": {
+        "type": "boolean"
+      },
+      "id": {
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "url": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "message",
+      "url",
+      "dismissible"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

AddedOct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructive=true, idempotent=true and openWorld=true, yet the description adds real behavioral context: the irreversible loss of verification (a new TXT check is required to re-add), cancellation of pending claims, the confirmation gate that makes the first call a no-op, and the explicit scope limit that no deployment, instance or cluster is deleted. The named refusal code and its remediation step are additional value not present in the annotations.

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 effect, then the protocol, then the error loop; every sentence carries operational information and nothing is filler. It is delivered as one dense block of long clauses, though, so paragraph or bullet structure would make the confirm sequence and the DOMAIN_IN_USE loop easier to parse at a glance.

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, open-world mutation with an output schema, the description covers everything an agent must know: the confirmation sequence, what the second call reports, the refusal handling, and the blast radius. Since an output schema exists, it correctly does not spend words on the return shape.

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 both parameters are already documented and the baseline is 3. The description still adds meaning by embedding confirm in a full two-call protocol and explaining what the unconfirmed call returns, which is more than the schema's one-line gate note.

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?

Opens with a specific verb and resource ("Removes a custom domain from this account") and immediately states the two effects: verification is dropped and a pending claim is cancelled. That distinguishes it from verify_domain, set_cluster_domain and delete_dns_entry, which operate on adjacent but different objects.

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 describes a two-call protocol: the first call releases nothing and only surfaces the domain for approval; confirm:true is passed only after the user says yes. It also names the refusal path, the DOMAIN_IN_USE condition, and routes the agent to delete_dns_entry before retrying, which is exactly the when-to-use/when-to-use-something-else information an agent needs.

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

All mcp 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.

Resources

Need Help?