Skip to main content
Glama
midPoint MCP Server

midPoint MCP Server

Create user

create_user

Create a new midPoint user with login name, full name, and email details; writes require the write gate, otherwise return a dry-run preview.

Instructions

Create a new midPoint user. Requires the write gate; otherwise returns a dry-run preview. When you write to a person, name people, roles and requests by their display names rather than OIDs.

Input Schema

NameRequiredDescriptionDefault
nameYesthe user's login name (required)
fullNameNodisplay/full name
givenNameNogiven (first) name
familyNameNofamily (last) name
emailAddressNoemail address

Output Schema

NameRequiredDescriptionDefault
bodyNothe JSON body of the midPoint REST request, when it has one
dryRunYes
methodYes
resultNo
appliedYes
summaryYes
endpointYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the important behavioral trait: without the write gate the call degrades to a dry-run preview rather than failing. It does not cover duplicate-name handling, validation failures, or whether the write is reversible, so it stops short of a 5.

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?

Three short sentences with no filler, and the core action is front-loaded ahead of the gating caveat. The final sentence is only loosely relevant to this tool's schema, which costs it a perfect score.

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?

An output schema exists, so return values need not be explained, and all five inputs are schema-documented; the write-gate behavior is the one piece of non-schema context an agent needs and it is present. What is missing is failure-mode context such as duplicate login names, which matters for a create operation.

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 every one of the five parameters is already documented and the baseline is 3. The extra sentence about naming people, roles and requests by display name is generic write guidance and does not actually map onto this tool's parameters (name, fullName, givenName, familyName, emailAddress), so it adds little parameter-level meaning here.

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?

"Create a new midPoint user" gives a specific verb and resource, and creation is clearly distinct from the sibling read (get_user) and lifecycle tools (disable_user, enable_user, recompute_user). It does not explicitly name a sibling to route away from, which keeps it short of a 5.

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

Usage Guidelines3/5

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

The description supplies a key prerequisite (the write gate) and states the fallback behavior when the gate is closed (dry-run preview), which effectively tells the agent when the call will actually mutate state. It gives no explicit when-to-use-vs-alternative guidance, e.g. how this relates to request_role or assign_role when a user also needs roles.

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