Skip to main content
Glama

update_user

DestructiveIdempotent

Change Nextcloud user account fields in one call: display name, email, password, quota, language, manager, groups, and subadmin groups. Only supplied fields change; invalid fields reject all changes.

Instructions

Change several fields of a user account in one call. Needs Nextcloud 34 or newer.

Only the fields you pass are changed. Nextcloud validates all of them first and applies none if one fails; the error then names each rejected field. A few requests are skipped without an error, so compare the returned "groups" and "subadmin" with what you asked for: a sub-admin cannot take the user out of groups they do not administer, only full admins can add someone to "admin", and nobody can be made sub-admin of "admin".

Changing another user needs admin rights, or sub-admin rights over one of their groups; sub-admin groups need admin rights. Any user can change their own display name (if the instance allows it), email, language and password. Nextcloud only accepts this call from admins and sub-admins, though, so for a regular user's own account the fields are set one by one instead, and a rejected field then no longer undoes the ones set before it.

After changing your own password, the old one stops working, including for this server if it logs in with it; app passwords keep working.

Args: user_id: The user to change. Example: "john.doe" display_name: New display name. An empty string resets it to the user ID. email: New primary email address. An empty string removes it. password: New password. Must satisfy the instance's password policy. Needs the destructive permission level, since the old password is gone afterwards. quota: Storage quota, e.g. "5 GB", "500 MB", a byte count, "none" (unlimited) or "default". language: Language code, e.g. "en", "de", "fr". manager: User ID of the user's manager (Nextcloud does not check that it exists). An empty string removes it. groups: The complete list of group IDs the user should be in: groups missing from it are left, new ones joined, and [] leaves every group. Get the current ones with get_user and IDs with list_groups. Needs the destructive permission level, since it can remove memberships. Taking your own account out of "admin" this way is refused. subadmin_groups: The complete list of groups the user should administer as a sub-admin; [] removes all. Needs the destructive permission level.

Returns: JSON with the user's details after the change, as get_user returns them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNo
quotaNo
groupsNo
managerNo
user_idYes
languageNo
passwordNo
display_nameNo
subadmin_groupsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.9/5.0
Behavior5/5

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

Far exceeds the annotation hints (destructiveHint/idempotentHint): it discloses atomic validation ("applies none if one fails", error names each rejected field), silent skips that require re-checking "groups"/"subadmin", permission edge cases (sub-admin group removal, adding to "admin"), and that a self password change invalidates the old password.

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?

The description is long but front-loaded with purpose and organized into behavioral rules, Args, and Returns. Nearly every sentence adds non-obvious behavior, though a few permission clauses could be tightened without losing meaning.

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

Completeness5/5

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

Complete for a high-complexity mutation tool: prerequisites, atomicity, partial-skip behavior, side effects, and parameter meanings are all covered. The output schema is referenced indirectly ("as get_user returns them") while still flagging that returned groups/subadmin may differ from what was requested.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does: it documents all nine arguments, including empty-string semantics (reset display_name, remove email/manager), quota formats, group-list replacement behavior, and which fields require the destructive permission level.

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?

Opens with a specific verb+resource ("Change several fields of a user account in one call"), and the phrasing distinguishes it from create_user, delete_user, and set_user_enabled among siblings. An agent can immediately tell this is the multi-field mutation tool for an existing user.

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

Usage Guidelines5/5

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

Explicitly states when it can be used and when not: own-account edits by regular users call the fields one by one instead, since the server rejects this call for them; other users need admin or sub-admin rights. It also names sibling helpers (get_user, list_groups) for resolving group IDs.

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