Polarion MCP Server

postTestStepResults

Create test step results for a Polarion test run. Preview requests with dry_run before sending to avoid duplicates.

Instructions

Creates a list of Test Step Results. Effect: creates a new resource on each call — calling it again with the same input creates a duplicate; it is not 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

Name	Required	Description
`dry_run`	No	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.
`iteration`	Yes	The iteration number identifying which repeated occurrence of this item is being addressed (e.g. which run of a test parameter).
`projectId`	Yes	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.
`testRunId`	Yes	The Test Run's ID within its project.
`testCaseId`	Yes	The Test Case's ID being referenced.
`requestBody`	Yes	The Test Step Result(s) body.
`testCaseProjectId`	Yes	The project ID that owns the referenced Test Case — may differ from the project in the request path when the test case is shared from another project.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.2.0Sep 17, 2026

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 / iteration / description

Previous value: -"The Iteration Number."New value: +"The iteration number identifying which repeated occurrence of this item is being addressed (e.g. which run of a test parameter)."

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."

changedInput schema / properties / testCaseId / description

Previous value: -"The Testcase ID."New value: +"The Test Case's ID being referenced."

changedInput schema / properties / testCaseProjectId / description

Previous value: -"The Testcase Project ID."New value: +"The project ID that owns the referenced Test Case — may differ from the project in the request path when the test case is shared from another project."

changedInput schema / properties / testRunId / description

Previous value: -"The Test Run ID."New value: +"The Test Run's ID within its project."

Changed1 schema field changedv1.1.0Sep 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "items": {
+        "properties": {
+          "id": {
+            "example": "MyProjectId/MyTestRunId/MyProjectId/MyTestcaseId/0/1",
+            "type": "string"
+          },
+          "links": {
+            "properties": {
+              "self": {
+                "example": "server-host-name/application-path/projects/MyProjectId/testruns/MyTestRunId/testrecords/MyProjectId/MyTestcaseId/0/teststepresults/1",
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": {
+            "enum": [
+              "teststep_results"
+            ],
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 7, 2026

addedInput schema / properties / dry_run

Added value: +{
+  "description": "If true, validate and return the request that would be sent without calling Polarion.",
+  "type": "boolean"
+}

First observedv1.0.0Jun 13, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already indicate idempotentHint=false, but the description reinforces this and adds valuable context: the dry_run behavior, the error-flagged preview, and the instruction to read text content regardless of the flag. No contradiction 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.

Conciseness5/5

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

Three sentences, each with a distinct purpose: purpose, non-idempotency, and dry_run tip. Front-loaded with the core action, no filler.

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 7-parameter tool with nested objects and an output schema, the description covers key behavioral aspects (non-idempotency, dry_run). It doesn't need to explain return values since output schema exists. Minor gap: no explicit mention of prerequisites beyond schema, but that's acceptable.

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 description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only references dry_run which is already documented in the schema. No need to compensate for gaps.

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 a list of Test Step Results, a specific verb-resource pair. It explicitly notes non-idempotency, which distinguishes it from getTestStepResults (read) and patchTestStepResults (update) among siblings.

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

Usage Guidelines3/5

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

It states this is a create operation and warns about duplication, but does not explicitly contrast with sibling update tools (e.g., patchTestStepResults) or state when NOT to use it. The dry_run tip implies a safe preview workflow but lacks explicit alternative routing.

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

Deploy Server