Spinnaker MCP server: community, and no Kayenta

A third-party connector covering Spinnaker's pipelines and infrastructure in depth, and the half of the product it does not reach at all.

Last verified 25 August 2026 · from The community repository, npm and the server's own tools/list response

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.

What is the Spinnaker/Kayenta MCP server?

The five-star GeiserX/spinnaker-mcp community package exposes Spinnaker pipelines and the infrastructure they deploy to. It uses the Model Context Protocol.

The tools map onto Spinnaker's own API surface through Gate. list_pipelines and get_pipeline_history read configuration, list_executions and get_execution read runs, and get_console_output reaches the logs from a stage.

One tool is unusual and useful. evaluate_expression evaluates a Spring Expression Language expression against a pipeline execution context, which is how an agent inspects pipeline variables and stage outputs without guessing.

It sits in CI and release, touches production observability through cluster state, and reaches nothing in code review, agent observability or cost.

Spinnaker's connector answers what was deployed and the resulting pipeline state. It can trigger a pipeline and read failed console output. It cannot judge a canary, and it cannot see how the application behaves. Pair it with a telemetry connector.

What can an AI agent do with Spinnaker/Kayenta?

list_strategies and save_strategy are the only tools that mention canary, and they cover Spinnaker deployment strategies such as red/black and rolling. Neither runs an automated canary judgment.

What connecting costs before the first question

A context window is the amount of text a model can hold at once, and connecting uses some of it before the agent asks anything. Every tool the server registers sends its name, description and input schema to the model when the session starts. The tool list is charged whether or not a single tool is called.

37 tools cost between 3,996 and 7,767 tokens, which is 2.0% to 3.9% of a 200,000-token window.

Both halves are compact. Descriptions average 260 characters and schemas 237, so a wide surface stays cheap.

Encodings: GPT-5.6, GPT-5.5 o200k_base; GPT-4, GPT-3.5 cl100k_base; Claude Haiku 4.5 to Opus 5 count_tokens. Counted 25 August 2026 from tools/list on the released npm package 0.3.3. It was run locally against a placeholder Gate URL.

Registration is static, so no Spinnaker instance answered. Figures cover name, description and input schema.

The two models in column one share the o200k_base encoding, so they get one count. The spread is formatting, about 46%. Reasoning tokens are output, spent per request. The tool list is input, charged once at connection.

The Claude figures are measured rather than encoded. Anthropic publishes no local tokenizer. So the definitions were sent to the API's count_tokens endpoint, and a no-tools baseline was subtracted. The range covers two tokenizer generations rather than two serializations. Haiku 4.5 and Opus 4.6 sit at the low end. Opus 5 and Sonnet 5 sit at the high end. The gap between them is about a third.

Spinnaker/Kayenta MCP server limits: where answers come back incomplete

The first limit is the half of the name this connector does not reach. No tool performs a Kayenta canary analysis.

How to configure Spinnaker/Kayenta MCP for agents

1. 1

   Treat it as unaffiliated software

   It is not from the Spinnaker project, and it is GPL-3.0 rather than Spinnaker's own license.

2. 2

   Decide who may deploy

   trigger_pipeline starts a real deployment, and delete_pipeline removes configuration permanently.

3. 3

   Do not plan on canary analysis

   No tool reaches Kayenta, so an agent cannot judge a canary through this connector.

4. 4

   Scope the Gate credentials

   Spinnaker's own authentication decides what the agent can reach, because the server has no permission model of its own.

Paste this into your agent’s instructions

Two tools mention canary and neither performs one, and ten tools change live deployments. Both need naming in the answer.

When you answer using Spinnaker MCP tools, state:
- The application and pipeline the answer covers.
- Whether you triggered, canceled, paused, resumed or
  restarted anything, and on which execution.
- That no tool performs a Kayenta canary analysis, if the
  question was about canary results.
Never state that data does not exist. State that no
executions matched the filters above.
Write your answer in ASD-STE100 Simplified Technical
English. Use short sentences with one idea in each.

Do you need the MCP server at all?

Not for automation. Spinnaker's Gate API is the direct route, and for a scripted trigger it avoids both the context cost and an unreviewed dependency.

The connector earns its place during a failed deployment. An agent moves from the execution, to its console output, to a SpEL expression, and that loop is what it is good at.

For canary judgment, Kayenta's own interface is the only route. Nothing in MCP reaches it.

Connect it to investigate a failed pipeline. Use Gate directly for anything scripted, and Kayenta's interface for canary results.

Spinnaker/Kayenta MCP server setup

The package runs with npx and needs the URL of your Spinnaker Gate service. Authentication is whatever your Gate already enforces.

It is registry-listed, so clients that read the official MCP registry can find it without a manual configuration.

claude mcp add-json "spinnaker" '{"command":"npx",
  "args":["-y","spinnaker-mcp"],
  "env":{"SPINNAKER_URL":"https://gate.internal"}}'

{"mcpServers":{"spinnaker":{"command":"npx",
  "args":["-y","spinnaker-mcp"],
  "env":{"SPINNAKER_URL":"https://gate.internal"}}}}

[mcp_servers.spinnaker]
command = "npx"
args = ["-y", "spinnaker-mcp"]
env = { SPINNAKER_URL = "https://gate.internal" }

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

{"mcpServers":{"spinnaker":{"command":"npx",
  "args":["-y","spinnaker-mcp@0.3.3"],
  "env":{"SPINNAKER_URL":"https://gate.internal"}}}}

Read-only access, permissions and security

• This is not Spinnaker's software

  It is a third-party project with 5 stars, under GPL-3.0, and nobody at the Spinnaker project has reviewed it.

• Ten tools change state

  Triggering, cancelling, pausing, resuming and restarting executions, plus saving, updating and deleting pipelines and strategies.

• One deletion is permanent

  delete_pipeline says in its own description that the action cannot be undone.

• Gate is the boundary

  The server has no permission model, so whatever your Gate service allows the credentials to do is what the agent can do.

Troubleshooting

Nothing returns from any tool

Check the Gate URL. The server registers all 37 tools whether or not Spinnaker is reachable, so an unreachable Gate looks like empty data.

A canary question cannot be answered

No tool reaches Kayenta. list_strategies and save_strategy cover deployment strategies such as red/black and rolling, which is a different concept.

A pipeline disappeared

delete_pipeline is in the default tool list and its description states the action cannot be undone.

Pipeline variables are unclear

Read the execution first with get_execution. Then compose a SpEL expression for evaluate_expression, which returns stage outputs and variables directly.

Spinnaker/Kayenta MCP server: Reference

What engineers report

The absence of an official server is the finding here, so the searches matter as much as the repository facts.

The spinnaker GitHub organization, spinnaker.io's sitemap and the official MCP registry were searched for both Spinnaker and Kayenta on 24 August 2026. Only the community server was found, and no Kayenta server of any kind. Tool counts come from the released npm package's own tools/list response.

Should you connect an agent to Spinnaker/Kayenta?

Only if a community server is acceptable to you. Best for read-heavy investigation on a pinned version, with the Gate credentials scoped away from production deploys.

Strongest fit

Spinnaker teams comfortable running an unaffiliated connector against a scoped Gate service.

Main advantage

Broad, cheap coverage of pipelines and infrastructure, with SpEL evaluation for inspecting a stuck execution.

Main weakness

No Kayenta coverage at all, which is half of what the name promises.

Operational risk

Ten writing tools including a permanent pipeline deletion, on software the Spinnaker project has not reviewed.

Frequently asked questions