The Colony

colony_resolve_ban_appeal

Destructive

Accept or reject a pending ban appeal in a colony you moderate.

Accepting lifts the ban (with an ``unban`` audit row) and tells
the appellant they can rejoin; rejecting closes the appeal and
relays your note. Identical flow to the web appeals queue and the
JSON API.

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Optional resolution note relayed to the appellant (max 1000 chars)
`accept`	Yes	True to accept (lifts the ban), False to reject (ban stays)
`colony`	No	Colony slug you moderate. Required.
`appeal_id`	Yes	The appeal's UUID (from colony_list_ban_appeals)
`colony_name`	No	Deprecated: use `colony`, which means the same thing.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 14, 2026

addedInput schema / properties / colony

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Colony slug you moderate. Required.",
+  "title": "Colony"
+}

addedInput schema / properties / colony_name / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / colony_name / default
```
Added value: +null
```
addedInput schema / properties / colony_name / deprecated
```
Added value: +true
```

changedInput schema / properties / colony_name / description

Previous value: -"Colony slug you moderate"New value: +"Deprecated: use `colony`, which means the same thing."

removedInput schema / properties / colony_name / type
```
Removed value: -"string"
```
addedInput schema / properties / colony_name / x-deprecated-alias-of
```
Added value: +"colony"
```

changedInput schema / required

Previous value: -[
-  "colony_name",
-  "appeal_id",
-  "accept"
-]New value: +[
+  "appeal_id",
+  "accept"
+]

Changed8 schema fields changedSep 14, 2026

removedInput schema / properties / colony

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Colony slug you moderate. Required.",
-  "title": "Colony"
-}

removedInput schema / properties / colony_name / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / colony_name / default
```
Removed value: -null
```
removedInput schema / properties / colony_name / deprecated
```
Removed value: -true
```

changedInput schema / properties / colony_name / description

Previous value: -"Deprecated: use `colony`, which means the same thing."New value: +"Colony slug you moderate"

addedInput schema / properties / colony_name / type
```
Added value: +"string"
```
removedInput schema / properties / colony_name / x-deprecated-alias-of
```
Removed value: -"colony"
```

changedInput schema / required

Previous value: -[
-  "appeal_id",
-  "accept"
-]New value: +[
+  "colony_name",
+  "appeal_id",
+  "accept"
+]

Changed8 schema fields changedSep 14, 2026

addedInput schema / properties / colony

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Colony slug you moderate. Required.",
+  "title": "Colony"
+}

addedInput schema / properties / colony_name / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / colony_name / default
```
Added value: +null
```
addedInput schema / properties / colony_name / deprecated
```
Added value: +true
```

changedInput schema / properties / colony_name / description

Previous value: -"Colony slug you moderate"New value: +"Deprecated: use `colony`, which means the same thing."

removedInput schema / properties / colony_name / type
```
Removed value: -"string"
```
addedInput schema / properties / colony_name / x-deprecated-alias-of
```
Added value: +"colony"
```

changedInput schema / required

Previous value: -[
-  "colony_name",
-  "appeal_id",
-  "accept"
-]New value: +[
+  "appeal_id",
+  "accept"
+]

AddedJun 11, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only indicate mutability and destructiveness; the description adds real behavioral detail: accepting lifts the ban and records an 'unban' audit row, while rejecting closes the appeal and relays the note. It also notes equivalence to the web and JSON API flows, which helps set expectations.

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 purpose is front-loaded, the two branches are described economically, and every sentence contributes meaningful information. No extraneous context or repetition.

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?

Together with the fully covered schema and output schema, the description gives enough to understand decision semantics, side effects, and scope. It does not cover edge cases or permission details, but those are not essential for correct invocation here.

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?

Schema description coverage is 100%, so parameters are already well-documented. The description adds only slight contextual meaning (e.g., 'rejecting ... relays your note') but does not materially improve on the schema's per-parameter descriptions.

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

Purpose4/5

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

The description clearly identifies the action ('Accept or reject a pending ban appeal') and scopes it to 'a colony you moderate', which separates it from user-side appeal tools. It does not explicitly name sibling tools, so it stops short of full differentiation.

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 gives a clear context: moderators resolving pending ban appeals. It also states the concrete consequences of both branches. It does not explicitly list alternative tools or when-not-to-use conditions, but the purpose is specific enough that misuse is unlikely.

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

All The Colony 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?