Skip to main content
Glama

Delete an account group

delete_group
DestructiveIdempotent

Deletes a group. Its accounts and posts stay; posts just stop remembering the group as a target. Cannot be undone through the API (create_group makes a new one).

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": {
      "workspace_id": "<workspace_id>",
      "group_id": "<group_id>"
    },
    "name": "delete_group"
  }
}

Input Schema

NameRequiredDescriptionDefault
group_idYes
workspace_idYesWorkspace id from list_workspaces

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations' destructive and idempotent hints, the description discloses exactly what survives (accounts and posts) and what changes (posts stop targeting the group), plus that the operation cannot be undone through the API. This is unusually strong behavioral context for a destructive mutation.

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?

Three short sentences, front-loaded with the action and followed by the key side effects and irreversibility. Every sentence earns its place.

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?

For a destructive two-parameter mutation with annotations covering safety and idempotency, the description gives the essential impact and recovery context. It could be slightly more complete by pointing to list_groups for obtaining group_id, but no critical information is missing.

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 schema documents workspace_id but leaves group_id undescribed; the tool description does not mention either parameter or explain how to obtain a valid group_id. With only two required, clearly named parameters and 50% schema coverage, this is minimally adequate but adds no parameter-level meaning.

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 states a specific verb and resource ("Deletes a group") and immediately explains the resulting scope: accounts and posts remain, but posts stop referencing the group. This clearly distinguishes it from siblings like update_group and create_group.

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

Usage Guidelines3/5

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

Deletion is clearly implied by the verb, and the description notes that create_group can recreate a group. However, it does not explicitly say when to use delete_group versus update_group or list_groups, nor does it state prerequisites or exclusions.

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.

Resources