Skip to main content
Glama

Update Group

update_group

Rename a group or update its description in Docmost; requires workspace admin or owner permissions.

Instructions

Rename a group or change its description. Needs a workspace admin or owner.

Input Schema

NameRequiredDescriptionDefault
nameNoNew name; left out keeps it.
groupYesGroup name or id from list_groups.
descriptionNoShort description.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds the permission requirement, which is not in any structured field and is essential for a mutation tool. It does not mention name-collision behavior or whether partial updates are atomic, which keeps 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste. The action is front-loaded and the permission constraint follows immediately, with nothing padding the description.

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?

Output schema exists, all three parameters are documented, and annotations cover the safety profile, so the description is close to sufficient. The remaining gap is edge-case behavior on name conflicts or invalid group identifiers, which an agent would need when calling this against a live workspace.

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 100% and each parameter carries its own description ('New name; left out keeps it.', 'Group name or id from list_groups.'), so the schema does the heavy lifting. The description only restates which fields are mutable, adding no format or constraint detail beyond that. Baseline 3 is correct here.

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?

States a specific verb and resource pair: rename a group or change its description. That clearly separates it from create_group, list_groups, and add_group_members by implication, though no sibling is named explicitly.

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?

Gives a concrete prerequisite ('needs a workspace admin or owner'), which is real usage guidance an agent can act on. It does not state when not to use it, nor does it name create_group or list_groups as the alternative paths, so the routing burden is only partly addressed.

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