Skip to main content
Glama

update_work_item

DestructiveIdempotent

Update a Polarion work item by patching fields such as title, status, priority, and custom fields, or trigger workflow transitions. Replaces assignees and hyperlinks entirely.

Instructions

Update an existing Polarion work item.

PATCHes the supplied fields and follows up with a GET so the caller can confirm the change in current. None / empty string / empty list all mean leave unchanged — this tool exposes no path to clear a field.

description_html is RAW Polarion HTML, sent verbatim with no sanitization, so XSS/script filtering is delegated to Polarion's renderer — NEVER pass untrusted input. Pair with get_work_item(include_description_html=True) for the round-trip. For greenfield authoring use create_work_item(description=...) (Markdown) — the two format paths never mix.

hyperlinks and assignee_ids REPLACE the existing lists (pass the full list, not a delta). custom_fields is partial — omitted keys are preserved. Unknown custom-field IDs silently persist as ghost attributes; pass keys from a prior read to avoid creating them.

The module relationship is NOT exposed here: Polarion rejects PATCHes that attempt to modify it. To attach, detach, or move a work item between documents, use move_work_item_to_document / move_work_item_from_document.

Prefer workflow_action over a raw status edit so the project's transition rules run. workflow_action and change_type_to MUST be paired with at least one body field — Polarion rejects empty PATCH bodies (HTTP 400 "At least one of the members is required"). Direct status / severity / resolution writes are NOT validated server-side: unknown ids are stored verbatim as ghost values. priority only coerces non-numeric inputs to the project default; numeric strings outside the enum set also persist verbatim. Resolve valid ids first via list_work_item_enum_options(project_id, field_id, work_item_type).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesPolarion project ID.
work_item_idYesShort ID of an EXISTING work item (e.g. 'MCPT-042').
titleNoNew title (None to leave unchanged).
description_htmlNoNew raw Polarion HTML body (round-trip shape from get_work_item); '' is a no-op.
statusNoNew workflow status; prefer ``workflow_action`` for real transitions.
priorityNoNew priority string (e.g. '50.0').
severityNoNew severity classification.
due_dateNoNew due date 'YYYY-MM-DD'.
initial_estimateNoNew Polarion duration (e.g. '5 1/2d', '1w 2d').
resolutionNoNew resolution outcome; prefer ``workflow_action`` so workflow rules apply.
hyperlinksNoREPLACES the hyperlink list — pass the full list, not a delta.
assignee_idsNoREPLACES the assignee list — pass the full list, not a delta.
custom_fieldsNoPartial custom-field update; rich-text values must be ``{'type':'text/html','value':...}``.
workflow_actionNoWorkflow action ID (e.g. 'close'); must be paired with at least one body field.
change_type_toNoChange work-item type; RESETS status; must be paired with at least one body field.
include_current_description_htmlNoWhen True, return the post-PATCH raw HTML body in ``current.description_html``.
dry_runNoWhen True, return payload preview without calling Polarion.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
updatedYesTrue on a real update; False on dry-run.
dry_runYesWhether this was a dry-run.
currentYesPost-PATCH state for verification; None on dry-run.
changesYesMap of field names to their new values in the PATCH.
payload_previewYesJSON:API payload sent or previewed; None after real ops.
Behavior5/5

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

Beyond annotations (destructiveHint, idempotentHint, openWorldHint), description details that None/empty means leave unchanged (no clear path), XSS risks for description_html, replacement vs. partial update semantics for hyperlinks/assignee_ids/custom_fields, and ghost attribute behavior for unknown IDs.

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?

The description is lengthy but well-organized with paragraphs grouping related details. Every sentence adds value for the complex tool. Slightly front-loaded; could be trimmed slightly but justified by parameter count.

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

Completeness5/5

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

Given 17 parameters, 100% schema coverage, and an output schema, the description covers all critical aspects: round-trip GET, parameter semantics, edge cases (ghost values, no clear path), security warnings, and cross-references to sibling tools. No gaps identified.

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?

Despite 100% schema coverage, description adds valuable context: 'REPLACES the hyperlink list', 'must be paired with at least one body field' for workflow_action/change_type_to, and explanation of dry_run and include_current_description_html. It also clarifies that '' is a no-op for description_html.

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 clearly states the action 'Update an existing Polarion work item' and follows with specific verb-resource pairs. It distinguishes from siblings like create_work_item (for greenfield Markdown) and move_work_item_to/from_document (for module changes).

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

Usage Guidelines5/5

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

Explicit guidance is provided on when to use workflow_action vs. raw status, when to use move_work_item tools for module changes, and warnings about empty PATCH bodies. It also advises to resolve enum IDs via list_work_item_enum_options.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/devemberx/mcp-server-polarion'

If you have feedback or need assistance with the MCP directory API, please join our Discord server