Skip to main content
Glama
Sign In
Polarion MCP Server

Polarion MCP Server

by phillipboesger
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

patchGlobalCustomFields

DestructiveIdempotent

Replaces all global Custom Fields for a resource type and target type, deleting any field omitted from the request. Read the current list first and preview changes with dry_run before committing.

Instructions

Replaces the entire list of global Custom Fields for one resource type and target type: fields missing from requestBody are deleted, not merged. Read the current list with getGlobalCustomFields first and send every field you want to keep. Effect: irreversible — data removed or overwritten by this call cannot be recovered through the API. Tip: set dry_run: true first to validate the arguments and preview the exact request without sending it to Polarion. The executor returns this preview as normal text, and as structured content when the tool declares an output schema.

Input 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.
targetTypeYesThe configured subtype for this enumeration or custom field (e.g. `requirement` for a Work Item type). Use `~` (without quotes) when the configuration applies to every subtype.
requestBodyYesCustom Fields Body
resourceTypeYesThe Resource Type.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.0
    • changedInput schema / properties / targetType / description
      Previous value: -"Identifies the target resource type this operation applies to (e.g. `workitem`). Use `~` (no quotes) to mean no specific target type."New value: +"The configured subtype for this enumeration or custom field (e.g. `requirement` for a Work Item type). Use `~` (without quotes) when the configuration applies to every subtype."
  2. 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 / targetType / description
      Previous value: -"The Custom Field target type. (Use '~' when there is no specific type for the Prototype.)"New value: +"Identifies the target resource type this operation applies to (e.g. `workitem`). Use `~` (no quotes) to mean no specific target type."
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already flag destructiveHint and idempotentHint, but the description adds what those annotations cannot: replace-not-merge semantics, that omitted fields are deleted, and that the effect is irrecoverable through the API. It also explains the dry_run preview behavior and how the preview is surfaced, which is real added context beyond structured hints.

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?

Front-loaded with the destructive replace semantics, then the prerequisite, then the safety mitigation — a sensible order. Slightly long, and the final sentence about executor output formatting is meta-detail that could be trimmed without losing meaning.

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?

Covers the risk profile, the read-before-write step, and the safe validation path, which is what an agent needs for a destructive nested-body tool with no output schema. It leaves the internal shape of individual field objects to the schema, which is acceptable given full schema coverage.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds non-derivable meaning for requestBody: it is a full replacement set, not a patch, and must contain every field to keep. dry_run is echoed usefully but its semantics are already in the schema.

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?

States a precise verb and resource ('Replaces the entire list of global Custom Fields') scoped by resource type and target type, which immediately distinguishes it from the appending sibling postGlobalCustomFields and the single-field patchCustomField.

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?

Gives concrete operating guidance: read the current list with getGlobalCustomFields first and resend every field to keep, plus try dry_run first. It stops short of naming the alternative write tools (postGlobalCustomFields, deleteGlobalCustomFields) or stating when this replace path is preferable to them.

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