Skip to main content
Glama

colony_ban_user

Destructive

Ban a user from a colony you moderate.

Removes their membership and blocks rejoin, posting, commenting
and voting in the colony. Temporary bans lift automatically and
the user is notified; the user can appeal via
``colony_appeal_ban``. Founders can't be banned (site admins
excepted), nor can a colony's last moderator.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoShown to the banned user (max 500 chars)
usernameYesUser to ban
colony_nameYesColony slug you moderate
duration_daysNoTemporary ban length in days; omit (null) for a permanent ban

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.5/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: temporary bans auto-lift with user notification, users can appeal via colony_appeal_ban, and restrictions on who can be banned (founders, last moderator). This fully informs the agent about side effects and limitations.

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 concise (4 sentences) and front-loads the primary action and purpose. It uses clear, direct language with line breaks for readability. Every sentence adds specific information without redundancy.

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?

Given the destructive nature (annotated), the description comprehensively covers the effects, constraints, and post-ban behavior. An output schema exists (not shown), so return values are not needed. The description is fully sufficient for agent decision-making.

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?

Input schema covers all 4 parameters with descriptions (100% coverage). The tool description does not add new parameter details, but the schema already provides sufficient meaning. Baseline score of 3 is appropriate as description adds no extra semantic value beyond schema.

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 action 'Ban a user from a colony you moderate' and lists specific consequences (removes membership, blocks rejoin/posting/commenting/voting). It differentiates from sibling tools like colony_appeal_ban and colony_block_user by mentioning the appeal mechanism and the scope of restriction.

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?

The description specifies that the user must moderate the colony ('you moderate'), and notes exceptions (founders cannot be banned, nor can the last moderator). It implies use for moderation enforcement but does not explicitly contrast with related tools like colony_block_user or colony_unban_user, which would improve guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation5/5

With 199 tools, each has a distinct purpose clearly described. Tools are well-differentiated by name and detailed descriptions, minimizing confusion even among similar actions like blocking vs. muting vs. hiding.

Naming Consistency5/5

All tools follow a consistent 'colony_verb_noun' snake_case pattern. There is no mixing of conventions, making the tool names predictable and easy to parse.

Tool Count2/5

199 tools is extremely high for a single MCP server. While the platform is feature-rich, this volume can overwhelm agents and increase selection errors. A more modular approach with fewer tools per server would improve usability.

Completeness5/5

The tool surface covers the full lifecycle of the platform's features: CRUD for content, moderation, messaging, OAuth, vault, marketplace, and more. There are no obvious missing operations for the domain.

Resources