Skip to main content
Glama
Sign In
spinnaker-mcp

spinnaker-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

Pipeline config history

get_pipeline_history
Read-onlyIdempotent

Retrieve a pipeline configuration's revision history to audit changes or compare past versions. Returns JSON versions ordered by update time.

Instructions

Get the version history of a pipeline configuration showing past revisions. Use this to audit changes to a pipeline or compare previous configurations. Returns JSON array of historical pipeline versions ordered by update time.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pipeline_config_id": "<pipeline_config_id>"
    },
    "name": "get_pipeline_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of history entries to return (default 10)
pipeline_config_idYesPipeline configuration ID

Output Schema

NameRequiredDescriptionDefault
countNoNumber of records in items.
itemsNoThe records, when Gate answered with a list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.4.1
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of history entries to return (default: 10)"New value: +"Maximum number of history entries to return (default 10)"
    • addedInput schema / properties / limit / maximum
      Added value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "description": "The Gate response. A JSON object from Gate comes back as is; a JSON array comes back as {items, count}.",
+  "properties": {
+    "count": {
+      "description": "Number of records in items.",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "items": {
+      "description": "The records, when Gate answered with a list.",
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds the ordering semantics ('ordered by update time') and the array shape, but since an output schema exists the return-value detail is largely redundant. Adequate but not rich beyond annotations.

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?

Three short sentences with the purpose front-loaded and no filler. The final sentence about return format is partly redundant with the output schema, keeping it just below maximum.

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?

Purpose, use cases, and ordering are all stated, and the output schema plus annotations cover return values and safety. Nothing an agent needs to invoke it correctly is missing; only explicit sibling routing would improve it.

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%, with both the required pipeline_config_id and the limit (default 10, max 100) documented inline. The description adds no meaning about parameter behavior, so the baseline 3 applies.

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?

States a specific verb and resource ('Get the version history of a pipeline configuration') with the qualifier 'showing past revisions', which clearly separates it from get_pipeline (current config) and list_pipelines. The sibling distinction is implied rather than named, so it falls short of a 5.

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?

'Use this to audit changes to a pipeline or compare previous configurations' gives concrete use cases, which is more than most read tools offer. It does not, however, state when NOT to use it or name get_pipeline as the alternative for current state.

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