Skip to main content
Glama
Sign In
Polarion MCP Server

Polarion MCP Server

by phillipboesger
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

getWorkItemAttachmentContent

Read-only

Downloads the raw bytes of a Work Item attachment, returning images and UTF-8 text as readable content and other files as base64. Use it when you need the file itself, not its metadata.

Instructions

Downloads the raw file content of one Work Item attachment. Images (PNG, JPEG, GIF, WebP) come back as image content, UTF-8 text files as text, and any other file (PDF, Office, ZIP) as an embedded base64 resource; files over 20 MB are refused. Use this only when you need the file's bytes; for its metadata (fileName, contentType, size, author) call getWorkItemAttachment, and to discover attachment IDs call getWorkItemAttachments.

Input Schema

NameRequiredDescriptionDefault
revisionNoA specific repository revision (e.g. `1234`) to read the resource as it existed at that revision instead of the current HEAD. Omit to use the latest revision.
projectIdYesThe Polarion project ID (its URL segment, e.g. `myproject`), case-sensitive. Required to scope the request to one project. If the ID is unknown, ask the user; getProjects lists IDs only with global read access.
workItemIdYesThe Work Item's ID within its project (e.g. `WI-123`), not the combined `project/id` path used in some link payloads.
attachmentIdYesThe attachment's ID, as returned by the corresponding list- or get-attachments call for this resource.
response_formatNoResponse detail level. concise removes redundant HTML and JSON:API metadata and may use a small default fieldset on large lists; detailed preserves the complete response. Defaults to detailed.detailed

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.4
    • changedInput schema / properties / projectId / description
      Previous 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."New value: +"The Polarion project ID (its URL segment, e.g. `myproject`), case-sensitive. Required to scope the request to one project. If the ID is unknown, ask the user; getProjects lists IDs only with global read access."
  2. Changed1 schema field changedv1.4.0
    • addedInput schema / properties / response_format
      Added value: +{
+  "default": "detailed",
+  "description": "Response detail level. concise removes redundant HTML and JSON:API metadata and may use a small default fieldset on large lists; detailed preserves the complete response. Defaults to detailed.",
+  "enum": [
+    "concise",
+    "detailed"
+  ],
+  "type": "string"
+}
  3. Changed4 schema fields changedv1.2.0
    • changedInput schema / properties / attachmentId / description
      Previous value: -"The Attachment ID."New value: +"The attachment's ID, as returned by the corresponding list- or get-attachments call for this resource."
    • 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 / revision / description
      Previous value: -"The revision ID."New value: +"A specific repository revision (e.g. `1234`) to read the resource as it existed at that revision instead of the current HEAD. Omit to use the latest revision."
    • changedInput schema / properties / workItemId / description
      Previous value: -"The Work Item ID."New value: +"The Work Item's ID within its project (e.g. `WI-123`), not the combined `project/id` path used in some link payloads."
  4. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the readOnlyHint/openWorldHint annotations: it discloses the return encoding per file type (image content, UTF-8 text, base64 embedded resource for PDF/Office/ZIP) and a hard 20 MB refusal threshold. Those are exactly the behaviors an agent must anticipate before invoking.

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?

Two sentences, front-loaded with the core action and content-type mapping, then the sibling routing. No filler; every clause carries information an agent would otherwise have to guess.

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?

For a read-only attachment fetcher with 100% schema coverage and no output schema, the description supplies the missing return-shape information (per-type content encoding) and the size limit, so nothing needed for a correct call is absent.

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% and all five parameters (including revision and response_format) are documented in the schema itself. The description adds only the routing hint that attachmentId comes from getWorkItemAttachments, which largely duplicates the schema's own wording — baseline 3 is appropriate.

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 specific verb and resource ('Downloads the raw file content of one Work Item attachment') and immediately distinguishes itself from getWorkItemAttachment (metadata) and getWorkItemAttachments (ID discovery). An agent can pick the right tool without opening a schema.

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?

Explicit when-to-use ('only when you need the file's bytes') plus named alternatives with the condition that selects each: getWorkItemAttachment for fileName/contentType/size/author, getWorkItemAttachments to discover IDs. This is the full when/when-not/alternatives pattern.

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