Skip to main content
Glama

Change a user

wp_update_user
Destructive

Update an existing WordPress user account by changing only the email, first or last name, role, or password you provide, then return the updated user and ID.

Instructions

Update an existing user account: email, first and last name, role or password. Only the fields given change. Returns updated and id. Needs edit_users and the right to edit this user; a role change needs promote_users and the right to promote this user, takes only roles the account may assign (editable_roles) and, for an account that is neither a single-site administrator nor a super admin, cannot give rights the account lacks; demoting the last administrator is refused. A call that sets a role is refused (ab_mcp_busy) and changes nothing while another role change or user deletion runs through AlphaBridge; a call that loses that lock on the way (a renewed database connection) is refused too: noticed before the other fields are saved, it changes nothing, noticed after them, it leaves only the role unchanged, and the answer says which. These checks cover calls through AlphaBridge, not changes made in wp-admin at the same moment. When the password changes, WordPress e-mails a notice to the user's address; when the email changes, it e-mails the previous address, naming the new one (the filters send_password_change_email and send_email_change_email can switch these off). No undo point is recorded.

Input Schema

NameRequiredDescriptionDefault
idYesUser id, as wp_list_users or wp_get_user return it.
roleNoNew role slug; replaces the user's roles on this site. Empty or omitted: the role stays.
emailNoNew email address.
passwordNoNew password. Empty or omitted: the password stays.
last_nameNoNew last name; an empty string clears it.
first_nameNoNew first name; an empty string clears it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.10.0

TDQS

A4/5.0
Behavior5/5

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

Goes far beyond the annotations: required capabilities (edit_users, promote_users), role-escalation limits via editable_roles, refusal to demote the last administrator, the AlphaBridge lock/ab_mcp_busy contention semantics including exactly what survives a lost lock, the notification emails sent to old and new addresses, and the explicit 'No undo point is recorded'. This is unusually rich disclosure for a destructive mutation and is consistent with destructiveHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Purpose and partial-update semantics are correctly front-loaded, and nearly every clause carries real information. But the permission/role and lock paragraphs are semicolon-chained run-ons that are hard to parse in one pass, which hurts scanability for an agent deciding whether to call.

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?

For a destructive, non-idempotent mutation with no output schema, the description covers prerequisites, failure modes, partial-failure outcomes, side effects and the return shape ('Returns updated and id'). Nothing material is missing for a correct call.

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 the baseline is 3, but the description adds meaning the schema does not: a role value must come from the roles the account may assign (editable_roles), and role changes carry escalation constraints. The password/email side effects are also parameter-specific, adding context beyond the field descriptions.

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?

Opens with a specific verb+resource and enumerates the exact fields it touches ('email, first and last name, role or password'), which implicitly separates it from wp_update_user_meta and wp_create_user. It stops short of naming the sibling it is not, so an agent must infer the meta-vs-account boundary.

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?

Usage is implied by the field list and by 'Only the fields given change', which tells the agent this is a partial update rather than a create. However, no sentence says when to prefer this over wp_update_user_meta, wp_create_user or wp_delete_user, and the many conditional clauses are prerequisites rather than routing guidance.

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