Skip to main content
Glama

Change Space Member Role

change_space_member_role

Changes the role of a user or group in a Docmost space to admin, writer, or reader; space admin rights are required.

Instructions

Change the role of one user (email or id) or one group (name or id) in a space. Docmost keeps at least one admin per space. Needs admin rights in the space.

Input Schema

NameRequiredDescriptionDefault
roleYesadmin, writer or reader.
userNoThe user's email or id; give user or group.
groupNoThe group's name or id; give user or group.
space_idYesSpace id from list_spaces.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, closed-world mutation. The description adds real behavioral context beyond them: the admin-rights requirement and the invariant that Docmost keeps at least one admin per space, which tells the agent a demotion can fail.

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, no filler: what it does, the invariant, the permission requirement — in that order.

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, so return values need not be described. The description covers scope, prerequisites, and a failure-relevant constraint; only an explicit note on which sibling adds members versus which reassigns roles is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description adds the important semantic that user and group are alternatives ('one user ... or one group'), clarifying the anyOf parameters that the schema documents only individually.

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?

States a specific verb (change) and resource (role of a member in a space) and scopes it to one user or one group. The phrase 'in a space' implicitly separates it from change_workspace_role, and 'role' separates it from add_space_members.

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?

Gives the key precondition ('Needs admin rights in the space') and the targeting rule (one user or one group, not both). It does not explicitly point to change_workspace_role or add_space_members as alternatives, but the guidance is actionable.

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