midPoint MCP Server

Overview Schema Source Related Servers Discussions Admin

Release work item

release_work_item

Return a claimed approval work item to its offered group undecided so another group member can claim it; validates it is open, claimed by you, and group-assigned before release.

Instructions

Give an approval work item you claimed (claimed: true in list_work_items) back to the group it was offered to, undecided, so anyone in the group can claim it. Before writing anything it reads the case as you and refuses an item that is closed, not claimed, held by someone else, or assigned to you directly rather than offered to a group. The release executes as you. userName and roleName are the midPoint names (the unique name attribute, such as a login, not display names) of the objects the OIDs point to, as list and get results give them; the call is refused when they don't match, so the person confirming it reads the right names. Respects the write gate. When you write to a person, name people, roles and requests by their display names rather than OIDs.

Input Schema

Name	Required	Description
`caseOid`	Yes	OID of the case (caseOid from list_work_items)
`roleName`	Yes	midPoint name of the role (or other object) the request adds or removes; empty only when midPoint doesn't show you its name
`userName`	Yes	midPoint name (login) of the person the request is for; empty only when midPoint doesn't show you their name
`workItemId`	Yes	id of the work item within the case (id from list_work_items)

Output Schema

Name	Required	Description
`body`	No	the JSON body of the midPoint REST request, when it has one
`case`	No	the case name
`tool`	Yes	the tool that produced this result
`acting`	Yes	who midPoint executed this call as
`dryRun`	Yes
`method`	Yes
`object`	No	the focus the case changes
`result`	No
`server`	Yes	write gate, features and versions of this server
`target`	No	what was requested
`applied`	Yes
`caseOid`	Yes
`subject`	Yes	the identity midPoint executed the call as (or, in a dry run, would)
`summary`	Yes
`endpoint`	Yes
`confirmed`	Yes	true when the case read back after the call shows the change: a claimed item held by you alone, or a released item held by nobody (or no longer shown to you)
`offeredTo`	Yes	the group the item is offered to, or was claimed from
`workItemId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4/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 real work: it discloses a pre-flight read performed as the caller, the four refusal conditions, that the release executes under the caller's identity, and that a write gate applies. The remaining gap is that 'the write gate' is unexplained jargon and the effect on the item's state after release is only implied.

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?

Purpose is front-loaded in the opening sentence, followed by preconditions, then parameter semantics — a sensible order. The closing sentence about naming people, roles and requests by display name is a general output-style rule that sits awkwardly at the end of a write tool's description and is the weakest use of space.

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 four-required-parameter mutation with no annotations and an output schema present, the description covers the risk surface that matters: identity of execution, refusal conditions, and cross-field validation. It does not spell out what the tool returns or whether the released item becomes immediately claimable by others, but the output schema absorbs part of that load.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: userName and roleName must be the midPoint unique-name attribute matching the OIDs, and the call is refused when they disagree — an integrity check an agent would otherwise not expect. It also warns against passing display names, which the schema does not mention.

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 concrete verb and resource: give back a claimed approval work item to the group it was offered to, undecided. It implicitly distinguishes itself from the claim direction, but never names the siblings claim_work_item or decide_work_item, so an agent must infer those routes rather than being routed to them.

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?

Gives a clear precondition (claimed: true, per list_work_items) plus an explicit exclusion list — closed, not claimed, held by someone else, or assigned directly rather than offered to a group. It stops short of naming which sibling to use instead in each of those cases, but the when/when-not picture is unambiguous.

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