Create a new Nginx Proxy Manager user account with required name, nickname, and email. Optionally assign roles, set a password, or disable the user.
Create a new Nginx Proxy Manager user
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name | |
| Yes | Email address | ||
| roles | No | Roles (e.g., ["admin"]) | |
| nickname | Yes | Nickname | |
| password | No | Password for the user | |
| is_disabled | No | Disable the user |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states the operation is a creation, but does not disclose required permissions, handling of duplicate users, password behavior, side effects, or what happens to disabled/role fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of wasted words, but for a tool with six parameters and no annotations it is too terse to be considered well-structured. It is concise without being adequately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. While the input schema covers parameter details, the description omits behavioral context, permissions, and post-create effects that an agent would need to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter, including required fields. The description adds no additional meaning, constraints, or syntax beyond what the schema provides, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair: 'Create a new Nginx Proxy Manager user.' This clearly distinguishes it from sibling operations like npm_update_user, npm_delete_user, and npm_list_users. It does not explicitly name or compare itself to those alternatives, so it falls short of the highest clarity level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, when not to use it, prerequisites, or alternatives. The description only says what it creates, leaving all usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.