Skip to main content
Glama
Sign In

mu

by mu.micro
OverviewDiscussionsAdmin

Update groups

groups_update
Destructive

Manage invitations, membership and roles. Accept invitations before accessing a group. Removing yourself leaves; owners must transfer ownership first. Delete closes the group for everyone.

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": {
      "id": "<id>",
      "action": "<action>"
    },
    "name": "groups_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
valueNoDescription for describe, new name for rename, or member/admin/owner for role
actionYesinvite, accept, decline, remove, role, rename, describe or delete
accountNoLocal username for invite, remove or role; defaults to yourself for remove

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / action / description
      Previous value: -"invite, accept, decline, remove, role, rename or delete"New value: +"invite, accept, decline, remove, role, rename, describe or delete"
    • changedInput schema / properties / value / description
      Previous value: -"New name for rename, or member/admin/owner for role"New value: +"Description for describe, new name for rename, or member/admin/owner for role"
  2. Added

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the destructiveHint annotation, the description discloses meaningful consequences and prerequisites: accepting invitations is required before access, removing yourself leaves the group, ownership must be transferred before an owner can leave, and delete closes the group for everyone. This is valuable behavioral context consistent with destructiveHint=true. It does not cover auth or rate-limit traits, keeping it short of a 5.

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?

Four short sentences, front-loaded with the purpose before the action-specific constraints. Efficient with little waste, though the action-condition sentences are somewhat clipped and telegraphic.

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

Completeness3/5

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

For a multi-action tool with no output schema, the description covers some actions (accept, remove, delete) but leaves invite, decline, rename, describe and role unexplained. There is no return-value or result guidance and the action enum is not declared in the schema, so an agent must infer behavior for several operations.

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 coverage is 75%, so the schema already documents value, action and account. The description's action words (invite, remove, role, delete) loosely map to those parameters but add no syntax or format detail, and the required 'id' parameter has an empty schema description that the prose does not compensate for. Baseline 3 is appropriate.

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 names a specific domain of operations ('invitations, membership and roles') for the groups_update tool, distinguishing it from the read/list/create siblings. However, it presents itself as a broad umbrella rather than stating the concrete action-based nature (invite/accept/decline/remove/role/rename/describe/delete) that the schema actually exposes.

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?

It gives conditional guidance for specific actions ('Accept invitations before accessing a group', 'owners must transfer ownership first', 'Delete closes the group for everyone'), which implies when certain actions apply. But it never contrasts with alternatives or states clearly when to reach for this tool over groups_create/groups_read, leaving routing to inference.

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

All mu toolsInspect
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