Skip to main content
Glama

create_work_item_links

Creates outgoing links from a source work item to specified targets, supporting cross-project links and optional revision pins.

Instructions

Create one or more outgoing links from a single source work item.

All links share the same source (project_id / work_item_id) and are sent as a single bulk JSON:API request. For each spec target_project_id defaults to project_id for the common same-project case; pass it explicitly only for cross-project links. The orientation matches list_work_item_links(direction="forward") on the source.

Polarion does not validate link roles server-side: an unknown role is stored verbatim and never matches subsequent queries. Resolve valid roles by reading an existing link with list_work_item_links(direction="forward") on a similar work item in the same project.

Each spec's revision pins the link to a specific Polarion revision when set, otherwise the link targets the current HEAD. suspect marks the link as needing re-review (usually False for new links).

The returned link_ids are five-segment composites <srcProj>/<srcWI>/<role>/<tgtProj>/<tgtWI> in input order, and are the path identifiers for future delete/PATCH of the same links via delete_work_item_links.

Bulk semantics -- partial-failure hazard: behavior on mixed-success (e.g. one duplicate among otherwise valid links) is not currently characterised on this server. On any 4xx response, assume nothing was committed and re-query with list_work_item_links(direction="forward") before retrying. If you need per-link diagnostics, send one spec per call.

Phantom-success on same-role conflict: when the source work item is attached to a document, move_work_item_to_document auto-creates one outgoing link (role depends on project config -- see that tool's docstring). Posting a NEW link with the SAME role from the same source returns 201 and echoes the requested link_id -- but the new link is NOT persisted. The pre-existing auto-link remains the only forward link, with its original target. There is no error to detect this client-side. After every create on an in-document source, verify the actual stored state with list_work_item_links(direction="forward") on the source AND list_work_item_links(direction="back") on the intended target; if your link is missing, detach via move_work_item_from_document, create the link, then re-attach with move_work_item_to_document.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesSource work item's project ID.
work_item_idYesSource work item ID (the links' outgoing endpoint).
linksYesOne or more links to create under the source work item.
dry_runNoWhen True, return payload preview without calling Polarion.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
createdYesTrue on a real create; False on dry-run.
dry_runYesWhether this was a dry-run.
link_idsNoComposite 5-segment link ids in input order; empty on dry-run.
payload_previewNoJSON:API payload sent or previewed; None after real ops.
Behavior5/5

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

Annotations provide minimal hints (non-readonly, non-destructive, non-idempotent). The description enriches with critical behaviors: bulk semantics, partial-failure hazard, phantom-success on same-role conflict, unknown role storage, and link_id format. No contradictions 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.

Conciseness4/5

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

The description is well-structured with clear paragraph breaks and front-loaded purpose. While lengthy, each section serves a purpose (orientation, role caveat, parameter details, link IDs, hazards). Could be slightly trimmed but remains effective.

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 the tool's complexity, the description covers all necessary aspects: input explanation, return format, potential failures, and verification steps. The presence of an output schema reduces the burden, but the description still provides comprehensive usage context.

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%, providing baseline 3. The description adds value by explaining defaults (target_project_id), role validation, revision pinning, and suspect marking. It provides actionable context beyond schema, such as how to resolve valid roles.

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 it creates outgoing links from a single source work item, specifying verb and resource. It distinguishes from siblings like delete_work_item_links and update_work_item_links by focusing on creation.

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 on when to use, including default project_id behavior, role validation via list_work_item_links, and warnings about partial-failure and phantom-success. Suggests alternative approaches like sending one spec per link for diagnostics and verifying with list calls.

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