Skip to main content
Glama

create_document

Create a new Polarion document in a project space, specifying its unique identifier, title, type, and optional custom fields or homepage content. Establishes an empty document ready for content.

Instructions

Create a new Polarion document in a space.

First call list_documents and confirm module_name is unique in the space (a duplicate returns HTTP 409). Supply only enum ids from list_document_enum_options — unverified ids persist as ghosts. custom_fields keys are validated against the document type's existing schema; a key no document of that type uses is rejected.

Starts empty (or with optional home_page_content); add parts later via update_document / move_work_item_to_document. module_name is the persistent URL identifier.

home_page_content is Markdown → sanitized HTML; post-create round-trip is raw HTML via get_document(include_homepage_content_html=True)update_document. Each block element is stamped a unique id="polarion_mcp_N" (else the next read_document_parts 500s); <h1>..<h4> are skipped (rewritten to macro form on save).

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; take keys from a sibling document via get_document to avoid ghost keys; rich-text values must be ``{'type':'text/html','value':...}``.
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
document_nameYes
payload_previewYes
Behavior5/5

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

Annotations provide only basic hints (non-readonly, non-destructive). The description goes far beyond by detailing uniqueness checks, enum validation, ghost keys, markdown conversion, HTML id stamping, and error conditions (409, 500).

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 paragraphs and bullet points covering distinct aspects. It is longer but packs necessary detail; could be slightly more terse without losing value.

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?

Covers creation lifecycle: preconditions (enum uniqueness, key validation), creation behavior (empty start, dry run), post-creation steps (add parts via other tools), and output handling (with output schema available). Very complete.

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% with good descriptions, but the description adds critical context: module_name is the URL identifier, home_page_content is Markdown->HTML, custom_fields need specific formatting. This significantly aids correct usage.

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 starts with a clear verb+resource: 'Create a new Polarion document in a space.' It distinguishes itself from siblings like update_document and list_documents by detailing document creation specifics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit preconditions (call list_documents, use enum ids, validate custom_fields) and notes the duplicate HTTP 409 behavior. Does not explicitly contrast with other 'create' siblings but is thorough for its own context.

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