Skip to main content
Glama
Sign In
Inflectra Spira MCP Server

Inflectra Spira MCP Server

Official
by Inflectra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

product_get_artifact

Read-only

Retrieve a single Spira product artifact by ID and type, with optional comments, associations, coverage, or related details for project and test management.

Instructions

Retrieve a single artifact by ID from a Spira product.

artifact_type: incident|task|test_case|requirement|risk|release|test_set|test_run|automation_host|build|document release_id: required when artifact_type='build' include: test_steps (test_case), mitigations (risk), steps (requirement), comments (most types), associations (most types), coverage (requirement, test_case, release)

Input Schema

NameRequiredDescriptionDefault
includeNo
product_idNo
release_idNo
artifact_idYes
artifact_typeYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv2.1.0
    • removedInput schema / properties / artifact_id / title
      Removed value: -"Artifact Id"
    • removedInput schema / properties / artifact_type / title
      Removed value: -"Artifact Type"
    • removedInput schema / properties / include / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / include / items
      Added value: +{
+  "type": "string"
+}
    • removedInput schema / properties / include / title
      Removed value: -"Include"
    • addedInput schema / properties / include / type
      Added value: +"array"
    • removedInput schema / properties / product_id / anyOf
      Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / product_id / title
      Removed value: -"Product Id"
    • addedInput schema / properties / product_id / type
      Added value: +"integer"
    • removedInput schema / properties / release_id / anyOf
      Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / release_id / title
      Removed value: -"Release Id"
    • addedInput schema / properties / release_id / type
      Added value: +"integer"
    • removedInput schema / title
      Removed value: -"product_get_artifactArguments"
  2. First observedv1.1.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by explaining that include can expand test_steps, mitigations, steps, comments, associations, and coverage, and that release_id is required for builds.

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?

The description is short, front-loaded, and line-oriented by parameter. Every line adds useful information about valid types, conditional requirements, or include behavior, with 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 simple get-by-ID tool with an output schema, the definition covers the critical enum and conditional-parameter behavior. The only minor gap is that product_id is not explained, but the overall retrieval contract is clear.

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 0%, so the description must carry parameter meaning. It fully enumerates artifact_type values, documents the conditional release_id requirement for build, and lists valid include values, but it does not explain product_id or artifact_id beyond their names.

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 states a specific verb and resource: "Retrieve a single artifact by ID from a Spira product." It also enumerates all supported artifact types, and the phrase "single artifact by ID" distinguishes this direct lookup from the sibling search tools.

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?

The description makes the retrieval context clear: a single artifact fetched directly by ID, rather than a search or list operation. It does not explicitly name search_artifacts as the alternative, but the distinction from sibling search tools is strongly implied.

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