Skip to main content
Glama

Update Space Group

update_space_group
Destructive

Modify a Circle community space group's settings, including name, slug, visibility, moderators, and member automation; requires confirm=true for user-requested changes.

Instructions

Update Space Group. Changes community state and requires confirm=true for the user-requested action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
slugNo
accountNoNamed private Circle account; selects credentials, not a remote community ID.
confirmNoSet true only when the user asked for exactly this action.
payloadNoComplete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
payload_fileNoRegular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
space_group_idYesSpace Group ID
hide_members_countNo
is_hidden_from_non_membersNo
allow_members_to_create_spacesNo
moderator_community_member_idsNoArray of community member ids to add as moderators
hide_non_member_spaces_from_sidebarNo
automatically_add_members_to_new_spacesNo
add_members_to_space_group_on_space_joinNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.1
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."
  2. First observedv2.0.0

TDQS

C2.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the mutation/safety profile is covered. The description adds that it changes community state and mandates confirm=true, which is mildly useful context, but it does not say what is destroyed, what permissions are needed, or how partial updates behave.

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?

Two short sentences, front-loaded, with no filler or repetition. It is efficient, though the terseness borders on under-specification rather than being genuinely concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive 14-parameter tool with a nested payload object and no output schema, the description omits body-format selection, credential/account selection, and the scope of the state change. An agent would have to reverse-engineer most of the call contract from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 43% across 14 parameters, so the description is expected to compensate, yet it mentions only confirm. The mutual exclusivity of payload vs body flags vs payload_file, the account credential selector, and the moderator id array are left entirely to sparse schema text.

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

Purpose2/5

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

"Update Space Group" is a near-verbatim restatement of the tool name/title, so the first sentence carries no added information. "Changes community state" gestures at the resource but is vague and does not distinguish this tool from siblings like update_space, update_community, or update_paywall_group.

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

Usage Guidelines2/5

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

The only guidance is the confirm=true requirement, which is a precondition rather than a when-to-use statement. There is no indication of when an agent should call update_space_group versus update_space or update_community, and no exclusions or alternatives are named.

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

Deploy Server

Other Tools