update_user

SERVERMcp SOURCEhttps://sqladmin.googleapis.com/mcp

Medium RISK CLASS

Category Write

Parameters 74 required

Recommended Rate-limitedsee the rule below

Registry record Grade F, identity unverified Pull the record →

This record as markdown: /tools/com-googleapis-sqladmin-mcp/update-user.md

WHAT IT DOES

What update_user does on Mcp

AI agents use update_user to create or update resources in Mcp, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Mcp environment.

Parameter	Type	Required	Description
`host`	string	—	Optional. Host of the user in the instance.
`name`	string	Yes	Required. Name of the user in the instance.
`type`	string	Yes	Required. The user type. It determines the method to authenticate the user during login. The default is the database's built-in user type.
`project`	string	Yes	Required. Project ID of the project that contains the instance.
`instance`	string	Yes	Required. Database instance ID. This does not include the project ID.
`databaseRoles`	array	—	Optional. List of database roles to grant to the user. body.database_roles will be ignored for update request.
`revokeExistingRoles`	boolean	—	Optional. revoke the existing roles granted to the user.

Parameters from the server's own tool schema.

RISK

Why update_user is rated Medium

This is a Write operation because it creates or modifies data reversibly—specifically user roles and permissions on a database instance. While it affects access control, it does not irreversibly delete data (not Destructive), execute arbitrary code (not Execute), nor involve financial transactions (not Financial).

From the tool's definition Tool description states 'Update a database user' and mentions 'grant a user the `cloudsqlsuperuser` role, which can provide a user with many required permissions.' The tool modifies user permissions and roles in a Cloud SQL instance.

Risk signalsAccepts URL/endpoint input (host)

Attacks that exploit this kind of access

RECOMMENDED RULE

The rule that runs update_user safely

PolicyLayer is an MCP gateway: it sits between your AI agents and Mcp, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For update_user, this is the rule to start with:

update_user Rate-limited

update_user stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.

View as policy code

policy.json

{
  "version": "1",
  "default": "deny",
  "tools": {
    "update_user": {
      "limits": [
        {
          "counter": "update_user_rate",
          "window": "minute",
          "max": 30,
          "scope": "grant"
        }
      ]
    }
  }
}

LIMIT THIS TOOL → Instant setup, no code required.

The button opens the PolicyLayer dashboard: create your workspace, connect Mcp, apply this rule, and every update_user call is checked against it from then on.

FAQ

Questions about update_user

What does the update_user tool do? +

Update a database user for a Cloud SQL instance. A common use case for the update_user is to grant a user the cloudsqlsuperuser role, which can provide a user with many required permissions. This tool only supports updating users to assign database roles. * This tool returns a long-running operation. Use the get_operation tool to poll its status until the operation completes. * Before calling the update_user tool, always check the existing configuration of the user such as the user type with list_users tool. * As a special case for MySQL, if the list_users tool returns a full email address for the iamEmail field, for example {name=test-account, iamEmail=test-account@project-id.iam.gserviceaccount.com}, then in your update_user request, use the full email address in the iamEmail field in the name field of your toolrequest. For example, name=test-account@project-id.iam.gserviceaccount.com. Key parameters for updating user roles: * database_roles: A list of database roles to be assigned to the user. * revokeExistingRoles: A boolean field (default: false) that controls how existing roles are handled. How role updates work: 1. If revokeExistingRoles is true: * Any existing roles granted to the user but NOT in the provided database_roles list will be REVOKED. * Revoking only applies to non-system roles. System roles like cloudsqliamuser etc won't be revoked. * Any roles in the database_roles list that the user does NOT already have will be GRANTED. * If database_roles is empty, then ALL existing non-system roles are revoked. 2. If revokeExistingRoles is false (default): * Any roles in the database_roles list that the user does NOT already have will be GRANTED. * Existing roles NOT in the database_roles list are KEPT. * If database_roles is empty, then there is no change to the user's roles. Examples: * Existing Roles: [roleA, roleB] * Request: database_roles: [roleB, roleC], revokeExistingRoles: true * Result: Revokes roleA, Grants roleC. User roles become [roleB, roleC]. * Request: database_roles: [roleB, roleC], revokeExistingRoles: false * Result: Grants roleC. User roles become [roleA, roleB, roleC]. * Request: database_roles: [], revokeExistingRoles: true * Result: Revokes roleA, Revokes roleB. User roles become []. * Request: database_roles: [], revokeExistingRoles: false * Result: No change. User roles remain [roleA, roleB]. It is categorised as a Write tool in the Mcp MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

What parameters does update_user accept? +

update_user accepts 7 parameters: host, name, type, project, instance, databaseRoles, revokeExistingRoles. Required: name, type, project, instance. The full parameter table on this page comes from the server's own tool schema.

How do I enforce a policy on update_user? +

Register the MCP server in PolicyLayer and add a rule for update_user: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp. Nothing to install.

What risk level is update_user? +

update_user is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Can I rate-limit update_user? +

Yes. Add a rate_limit block to the update_user rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block update_user completely? +

Set action: deny in the PolicyLayer policy for update_user. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides update_user? +

update_user is provided by the MCP server (https://sqladmin.googleapis.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.

KEEP EXPLORING

More on , and thousands of servers like it.

This server

All 15 tools →

Across the catalogue

aroflo_create_or_update_record on AroFlo MCP → The MCP Attack Database →

Guides

Govern customer-ops agents →Argument validation →Scoped token →