Skip to main content
Glama

openwisp_create_user

Create a new OpenWISP user with role and organization permissions to control access. Provide username, email, and password via the API.

Instructions

[Category: Users & Auth] Create a new user in OpenWISP with role and organization permissions. (HTTP POST /api/v1/users/user/)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesEmail address
is_staffNoAdmin/staff privileges flag
passwordYesAccount password
usernameYesUnique username for the account
is_activeNoWhether the account is active
last_nameNoLast name
first_nameNoFirst name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0

TDQS

C2.9/5.0
Behavior2/5

Does 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 discloses the HTTP method/endpoint and category, but says nothing about required authentication/permission level, password policy constraints, uniqueness/conflict errors, or whether the created user is immediately active or needs activation via a sibling tool.

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

Conciseness4/5

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

A single compact sentence with the category tag and endpoint appended; the purpose is front-loaded with zero filler. The only inefficiency is the mention of fields the tool doesn't accept.

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?

With 7 parameters, no annotations, and no output schema, the description does not do enough: it omits auth requirements, side effects, and what the response contains. For an unannotated mutation endpoint this is a meaningful gap.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3 — each of the 7 fields is self-documented. The description adds no syntax or format guidance and instead references 'role and organization permissions' fields that do not exist in the schema, which is mildly misleading rather than additive.

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?

States a specific verb+resource ('Create a new user in OpenWISP') and tags the category and HTTP endpoint, which clearly distinguishes it from sibling read/delete user tools like openwisp_list_users and openwisp_delete_user. However, it claims the tool handles 'role and organization permissions,' which are not represented anywhere in the schema, slightly muddying exactly what this tool does.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no routing to alternatives (e.g., when to use openwisp_create_user vs inviting an existing user). The agent must infer everything from the endpoint path.

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