Skip to main content
Glama

create_work_items

Create between 1 and 50 Polarion work items in a single atomic request, with full validation of enums and custom fields to prevent ghost data.

Instructions

Create one or more Polarion work items (1-50) in one request, same project.

Confirm every enum value (type / status / severity / custom enums) via list_work_item_enum_options first — unverified ids persist as ghosts that never match Lucene. custom_fields keys are validated against the type's existing schema; a key no item of that type uses is rejected, and a type with no populated customs blocks the write (nothing to validate against). hyperlinks[].role validated against hyperlink-role.

Atomic: guards + conversion + build run before the POST; one bad item rejects the whole batch (nothing created). Raises if the returned id count differs from submitted — re-query list_work_items first.

Items are free-floating; place in a document via move_work_item_to_document (direct module create lands in the recycle bin). description is Markdown → sanitized HTML; the post-create round-trip is raw HTML via get_work_item(include_description_html=True)update_work_item.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesPolarion project ID.
itemsYesOne or more work items to create in a single request (1-50). Pass a single-element list to create just one.
dry_runNoWhen True, return the payload preview without writing; the enum guard still calls Polarion's getAvailableOptions, so that endpoint must be reachable.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
createdYes
dry_runYes
work_item_idsNo
payload_previewNo
Behavior5/5

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

Annotations are minimal (readOnlyHint=false, etc.), but description adds rich behavioral context: atomicity (one bad item rejects batch), id count mismatch raises error, free-floating items, description as Markdown→HTML, hyperlink role validation, custom_fields schema validation. Exceeds annotations significantly.

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?

Description is concise yet thorough, front-loaded with main purpose, then systematically covers prerequisites, validation, atomicity, and post-creation actions. Every sentence adds value without redundancy. Well-structured for agent consumption.

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 (batch creation, enum validation, atomicity, free-floating items), the description comprehensively covers prerequisites, behavioral details, edge cases, and next steps. Output schema exists, so return values are covered externally. Complete for effective use.

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?

Schema coverage is 100%, but description enhances parameters with critical details: hyperlinks[].role validated against 'hyperlink-role', custom_fields keys validated against type's schema, and relationship with enum options. Adds 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?

Clearly states 'Create one or more Polarion work items (1-50) in one request, same project.' Provides specific verb and resource with constraints (batch size, project scope), distinguishing from siblings like update_work_item and move_work_item_to_document.

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?

Explicitly instructs to confirm enum values via list_work_item_enum_options first and warns about ghost values. Advises using move_work_item_to_document for placement, stating direct module create lands in recycle bin. Also explains atomic behavior and error handling, providing clear when-to-use and when-not-to-use guidance.

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