Skip to main content
Glama

dokploy_user_update

dokploy_user_update
Idempotent

Update user account details in Dokploy, including profile information, security settings, subscription status, and access permissions.

Instructions

[user] user.update (POST)

Parameters:

  • id (string, optional)

  • firstName (string, optional)

  • lastName (string, optional)

  • isRegistered (boolean, optional)

  • expirationDate (string, optional)

  • createdAt2 (string, optional)

  • createdAt (any, optional)

  • twoFactorEnabled (any, optional)

  • email (string, optional)

  • emailVerified (boolean, optional)

  • image (any, optional)

  • banned (any, optional)

  • banReason (any, optional)

  • banExpires (any, optional)

  • updatedAt (string, optional)

  • enablePaidFeatures (boolean, optional)

  • allowImpersonation (boolean, optional)

  • enableEnterpriseFeatures (boolean, optional)

  • licenseKey (any, optional)

  • stripeCustomerId (any, optional)

  • stripeSubscriptionId (any, optional)

  • serversQuantity (number, optional)

  • password (string, optional)

  • currentPassword (string, optional)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
firstNameNo
lastNameNo
isRegisteredNo
expirationDateNo
createdAt2No
createdAtNo
twoFactorEnabledNo
emailNo
emailVerifiedNo
imageNo
bannedNo
banReasonNo
banExpiresNo
updatedAtNo
enablePaidFeaturesNo
allowImpersonationNo
enableEnterpriseFeaturesNo
licenseKeyNo
stripeCustomerIdNo
stripeSubscriptionIdNo
serversQuantityNo
passwordNo
currentPasswordNo
Behavior3/5

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

The description adds minimal behavioral context beyond annotations. Annotations indicate this is a mutable (readOnlyHint=false), non-destructive, idempotent, open-world operation. The description only adds that it's a POST request, which implies it's an update operation. However, it doesn't provide crucial behavioral details like authentication requirements, rate limits, what happens when specific fields are updated, or whether the update is partial/full. No contradiction with annotations exists.

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

Conciseness2/5

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

While technically concise, the description is under-specified rather than efficiently structured. It wastes space listing 24 parameter names without adding value, instead of providing meaningful context. The structure shows the HTTP method but doesn't front-load the most important information about what the tool does and when to use it. Every sentence (or in this case, the parameter listing) doesn't earn its place by adding explanatory value.

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

Completeness2/5

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

Given the complexity (24 parameters, mutation operation, no output schema, 0% schema coverage), the description is severely incomplete. It doesn't explain what a successful update returns, error conditions, required versus optional fields, field dependencies, or the update's effect on the system. For a user management tool with many sensitive fields (password, ban status, payment info), this lack of context is particularly problematic.

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

Parameters2/5

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

With 0% schema description coverage for 24 parameters, the description carries full burden for explaining parameters. It merely lists parameter names without any semantic explanation of what they mean, their relationships, or constraints. For example, it doesn't explain that 'id' or 'email' might be required for identification, what 'createdAt2' versus 'createdAt' represents, or the format for dates. The description fails to compensate for the complete lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is essentially a tautology - it restates the tool name 'user.update' without adding meaningful context about what the tool actually does. While it mentions 'POST' which indicates an HTTP method, it doesn't explain what resource is being updated or the scope of the operation. The description fails to distinguish this from sibling tools like 'dokploy_user_remove' or 'dokploy_user_get'.

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

Usage Guidelines1/5

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

There are absolutely no usage guidelines provided. The description doesn't indicate when to use this tool versus alternatives, what permissions are required, whether it's for admin vs regular users, or any prerequisites. With many sibling tools available (like dokploy_user_remove, dokploy_user_get, dokploy_user_createApiKey), the agent has no guidance on when this specific update tool is appropriate.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jarciahdz111/dokploy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server