Skip to main content
Glama

update_work_item_links

Update suspect or revision flags on an existing work item link. Clear a suspect flag after review or pin a link to a specific revision.

Instructions

Update suspect / revision on one existing outgoing work item link.

Use this to clear a suspect flag after a reviewer signs off, or to pin a link to a specific revision. Identify the link first with list_work_item_links(direction="forward"): the role and target work item ID together address one specific link.

suspect and revision are tri-state: an explicit True / False / string value updates that attribute, while None (the default) leaves the existing server-side value alone. This differs from create_work_item_links where suspect defaults to False (a concrete value). At least one of suspect / revision must be provided -- passing both as None is rejected because Polarion would 400 on the resulting empty PATCH body.

To update multiple links, call this tool once per link. Unlike create_work_item_links / delete_work_item_links, the PATCH endpoint has no server-side bulk equivalent.

Polarion does not validate link role ids server-side, so a typo in role returns 404 -- the link simply does not exist under that role.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesSource work item's project ID.
work_item_idYesSource work item ID (the link's outgoing endpoint).
roleYesLink role id of the existing link.
target_work_item_idYesTarget work item ID (the link's incoming endpoint).
target_project_idNoTarget's project; defaults to the source's project.
suspectNoNew suspect flag value; None leaves it unchanged.
revisionNoNew revision pin; None leaves the existing pin unchanged.
dry_runNoWhen True, return payload preview without calling Polarion.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
updatedYesTrue on a real PATCH; False on dry-run.
dry_runYesWhether this was a dry-run.
link_idYesComposite 5-segment id computed from inputs.
payload_previewYesJSON:API PATCH body; None after real ops.
Behavior5/5

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

Adds detailed behavioral context beyond annotations: tri-state meaning, difference from create_work_item_links, no bulk endpoint, and potential 404 due to typo. No contradiction with annotations.

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

Conciseness5/5

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

Well-structured and concise: each sentence serves a purpose, starting with a clear statement of action, followed by usage instructions, behavioral details, and caveats. No redundancy.

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?

Comprehensive coverage given the tool's complexity: explains purpose, identification of links, parameter behavior, constraints, and error cases. The output schema is assumed to handle return values.

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?

The description enriches schema descriptions by explaining tri-state semantics, the need for role+target to identify a link, and the constraint that at least one of suspect/revision must be provided. Schema coverage is 100% and the description adds further clarity.

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 tool updates suspect/revision on one existing link, differentiates from create_work_item_links and delete_work_item_links, and explains the tri-state behavior and the need to identify the link via list_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 guidance: when to use (clear suspect flag, pin revision), how to identify the link, tri-state handling, requirement for at least one field, and error scenarios (400, 404).

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