nc-mcp-server

create_user

Create a new Nextcloud user with a login name, password, display name, and email. Requires admin privileges and returns the created user ID.

Instructions

Create a new Nextcloud user. Requires admin privileges.

Args: user_id: Login name for the new user. password: Password for the new user. display_name: Display name. Defaults to user_id if empty. email: Email address for the new user.

Returns: JSON with the created user ID.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "user_id": "<user_id>",
      "password": "<password>"
    },
    "name": "create_user"
  }
}

Input Schema

Name	Required	Description	Default
`email`	No
`user_id`	Yes
`password`	Yes
`display_name`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Sep 21, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The annotations already signal this is a write operation (readOnly=false, idempotent=false, destructive=false), so the description does not need to restate that. It adds valuable context beyond the annotations: admin privileges are required, and the call returns JSON containing the created user ID. It does not mention duplicate-user errors or password constraints, but those are minor for a create operation at this level.

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

Conciseness5/5

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

The description is well-structured: a one-sentence purpose, a compact and readable Args block, and a Returns line. The admin-privilege warning is front-loaded. Every sentence earns its place, and there is no filler or repetition of schema information.

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

Completeness4/5

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

For a simple create operation, the description covers prerequisites, all four parameters, the display_name default behavior, and the return value. Minor gaps exist, such as not explicitly marking email as optional or stating password format constraints, but the schema already marks required fields and defaults, so an agent has enough to invoke the tool correctly.

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 of explaining the parameters. It does so thoroughly: user_id is the login name, password is the new user's password, display_name has a documented default to user_id, and email is the user's email address. This adds real semantic meaning the schema alone does not provide.

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?

The description opens with 'Create a new Nextcloud user,' a specific verb and resource that makes the tool's purpose unmistakable. It clearly distinguishes this tool from siblings like list_users, get_user, and delete_user by focusing on creation. The word 'new' also signals non-idempotent creation without relying on the annotation.

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

Usage Guidelines4/5

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

The description provides clear context by stating the tool creates a new user and explicitly adds the admin-privilege prerequisite. It does not name alternatives or exclusion conditions, but the use case is unambiguous against the sibling list. This is clear context without explicit when-not guidance.

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

Deploy Server