Skip to main content
Glama
phillipboesger

Polarion MCP Server

by phillipboesger
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

reopenCollection

Reopen a specified Polarion collection by project and collection ID. Use dry_run to preview the exact request before sending.

Instructions

Reopens the specified Collection. Effect: triggers a server-side action rather than a plain resource creation — whether repeating it is safe, a no-op, or rejected depends on the specific action; treat it as not guaranteed idempotent. Tip: set dry_run: true first to preview the exact request Polarion would receive, without changing anything. On tools with a typed output schema, this preview is returned as an error-flagged result since it is not real tool output -- read the text content regardless of that flag.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoIf true, validates the request and returns the exact request that would be sent to Polarion — with the Authorization header redacted and any binary payload summarized by byte length — without actually sending it.
projectIdYesThe Polarion project ID (its URL segment, e.g. `myproject`), case-sensitive. Required to scope the request to one project; call getProjects to list valid IDs.
collectionIdYesThe Collection ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • changedInput schema / properties / dry_run / description
      Previous value: -"If true, validate and return the request that would be sent without calling Polarion."New value: +"If true, validates the request and returns the exact request that would be sent to Polarion — with the Authorization header redacted and any binary payload summarized by byte length — without actually sending it."
    • changedInput schema / properties / projectId / description
      Previous value: -"The Project ID."New value: +"The Polarion project ID (its URL segment, e.g. `myproject`), case-sensitive. Required to scope the request to one project; call getProjects to list valid IDs."
  2. Added

TDQS

A3.5/5.0
Behavior4/5

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

With idempotentHint=false already present, the description adds meaningful context: it warns the operation is a server-side action whose repeated execution may be unsafe, a no-op, or rejected, and it recommends dry_run to preview without side effects. It also explains the error-flagged preview behavior. This is consistent with the annotations and adds value beyond them.

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 front-loaded with the core action and keeps the caveats to three sentences. The dry_run behavior is slightly redundant with the schema and the 'typed output schema' clause is tangential for this tool, but overall it is well-sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-required-parameter action with annotations covering idempotency and destructive behavior, the description gives sufficient warning and a safe preview path. It does not describe return values, but no output schema exists, and the missing usage routing is a smaller gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds only a dry_run recommendation, which the schema already describes in detail; it does not clarify collectionId beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a concrete verb ('Reopens') and a specific resource ('the specified Collection'), so an agent can tell what the tool acts on. It does not directly differentiate itself from closeCollection or reuseCollection, but 'reopens' is unambiguous enough to convey its core function.

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

Usage Guidelines2/5

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

There is no statement about when to call this tool instead of closeCollection or reuseCollection, nor conditions such as 'only for already-closed collections.' The only guidance is to use dry_run for previewing, which is about safe invocation rather than tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools