Skip to main content
Glama

create_document

Create a Polarion document in a space using project ID, space ID, module name, title, and type. Optionally add home page content, custom fields, or status.

Instructions

Create a new Polarion document in a space.

Greenfield document creation. The document starts empty (or with the optional home_page_content body) and headings / work item parts can be added later via update_document and move_work_item_to_document.

Format asymmetry: home_page_content here is Markdown (converted to sanitized HTML on write) because greenfield authoring is natural for LLMs. After creation the round-trip pair is get_document(include_homepage_content_html=True)update_document(home_page_content_html=...) which speaks raw HTML verbatim. The two formats never mix.

When home_page_content is provided, every block-level element of the rendered HTML (<p>, <ul>, <ol>, <table>, <div>, <blockquote>, <pre>) is stamped with a unique id="polarion_mcp_N" anchor. Without these ids the document saves but the next read_document_parts returns HTTP 500. Headings <h1>..<h4> are intentionally skipped — Polarion rewrites their ids into a polarion_wiki macro name=module-workitem macro form on save.

module_name is Polarion's persistent identifier within the space and is used in every subsequent URL (get_document, update_document, etc.). It must be unique within space_id; a duplicate name causes Polarion to return HTTP 409, surfaced here as RuntimeError.

Polarion does NOT validate enum membership server-side. Unknown type / status ids are stored verbatim as ghost values that look real on later reads but never match Lucene queries. Resolve valid ids first via list_document_enum_options(project_id, field_id, document_type). custom_fields is the same story: unknown field IDs silently persist as ghost attributes -- pass keys taken from a prior get_document.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesPolarion project ID.
space_idYesSpace ID (use '_default' for the default space).
module_nameYesPolarion document identifier (e.g. 'MySpecV1'); must be unique within ``space_id`` and appears in the document URL.
titleYesHuman-readable document title (required, non-empty).
typeYesDocument type (e.g. 'req_specification', 'generic').
statusNoOptional initial workflow status (project default applies if omitted).
home_page_contentNoOptional Markdown body; converted to sanitized HTML on write.
custom_fieldsNoOptional custom fields keyed by Polarion field ID; rich-text values must be ``{'type':'text/html','value':...}``.
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.
document_nameYesModule name of the new document; None on dry-run.
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?

Annotations indicate write operation (readOnlyHint=false). Description adds critical behavioral details: id stamping on block elements, requirement of ids for read_document_parts success, heading id rewrite, Polarion's lack of server-side enum validation leading to ghost values, and dry_run behavior. Goes far beyond 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 dense and well-structured, starting with the core purpose, then progressive details. Every sentence adds value, but it is relatively long (6 paragraphs). Could be slightly more streamlined, but still effective for a complex tool.

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 (9 params, output schema exists), the description covers creation workflow, format constraints, uniqueness, validation needs, ghost values, and dry_run. All critical aspects are addressed, making it fully complete without needing output schema details.

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 adds rich context: home_page_content is Markdown (not HTML), type/status require validation, custom_fields may produce ghost attributes, module_name must be unique. Dry_run parameter is explained as payload preview. Adds significant value beyond the 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 'Create a new Polarion document in a space' and contrasts with sibling tools like update_document and move_work_item_to_document. It specifies greenfield creation and optional home_page_content, making the tool's sole purpose unambiguous.

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 guidance: greenfield creation vs. later modifications via update_document or move_work_item_to_document. Warns about duplicate module_name causing HTTP 409, advises validating enums via list_document_enum_options, and explains format asymmetry for home_page_content. No alternatives are left unaddressed.

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