Skip to main content
Glama

move_work_item_to_document

Destructive

Move a work item into a Polarion document at a specific position, properly setting the module relationship and outline number. This is the only supported method to attach a work item body to a document.

Instructions

Move a work item into a Polarion document at a specific position.

Calls the moveToDocument action endpoint, which updates the work item's module relationship, inserts a document part at the specified position, and assigns a proper outline_number — atomically. This is the ONLY supported way to attach a work item body to a document; editing homePageContent directly to inject a macro reference leaves the module relationship unset and produces an inconsistent state.

Heading-type work items are rejected (HTTP 400 "Cannot move headings"); headings must be created inside their target document. If the work item is already in a different document, this detaches it from the source — the operation is a move, not a copy. To detach a work item back to free-floating (no document), use move_work_item_from_document — the module relationship cannot be cleared via PATCH.

Provide AT MOST one of previous_part_id (insert AFTER) / next_part_id (insert BEFORE); if both are omitted the work item is appended at the end of the target document. Discover part IDs with read_document_parts.

Side effect: this server auto-creates an outgoing link from the moved work item to its enclosing section heading. The role is project-configurable (commonly parent or relates_to), so discover it by inspecting forward links on a known-attached work item in the same project. The auto-link appears in list_work_item_links(direction="forward") after the move and is silently removed by move_work_item_from_document. The role collides with any same-role link created from the same source -- see the "phantom success" note on create_work_item_links.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesProject containing the work item.
work_item_idYesShort ID of an EXISTING work item (e.g. 'MCPT-042').
target_space_idYesTarget space ID (use '_default' for the default space).
target_document_nameYesTarget document name within ``target_space_id``.
previous_part_idNoInsert AFTER this part ID; mutually exclusive with ``next_part_id``. Omit both to append at the end of the target document.
next_part_idNoInsert BEFORE this part ID; mutually exclusive with ``previous_part_id``. Omit both to append at the end of the target document.
dry_runNoWhen True, return payload preview without calling Polarion.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
movedYesTrue on a real move; False on dry-run.
dry_runYesWhether this was a dry-run.
payload_previewYesRequest payload sent or previewed; None after real ops.
Behavior5/5

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

Discloses important side effects beyond annotations: auto-creation of an outgoing link, role discovery, and behavior on move. Annotations already indicate non-read-only and destructive, but description adds atomicity and module relationship details.

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?

Well-structured with clear paragraphs and bullet-like points. Could be slightly more concise, but every sentence adds value and is well-organized.

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?

Thorough coverage for a complex, multi-step operation with side effects and constraints. Output schema exists, so return values are not needed in description. All critical behavioral details are present.

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 coverage is 100%, so baseline 3. Description adds context for previous_part_id/next_part_id constraints but does not significantly extend meaning beyond schema descriptions.

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 'Move a work item into a Polarion document at a specific position.' It uniquely identifies the tool's action and resource, and distinguishes it from siblings like 'move_work_item_from_document' and 'create_work_item_links'.

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?

Provides explicit when-to-use and when-not-to-use guidance: heading work items are rejected, provide at most one of previous_part_id/next_part_id, and detaches from source document if already in another. It also names the alternative tool for detaching.

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