spinnaker-mcp

Overview Schema Source Related Servers Discussions Admin

Evaluate SpEL expression

evaluate_expression

Read-onlyIdempotent

Evaluates SpEL expressions against a Spinnaker pipeline execution context to inspect variables, stage outputs, and computed values for debugging, returning JSON while blocking unsafe patterns.

Instructions

Evaluate a Spring Expression Language (SpEL) expression against a pipeline execution context. Use this to inspect pipeline variables, stage outputs, or computed values during debugging. Dangerous patterns (reflection, class instantiation) are blocked for security. Returns the evaluated expression result as JSON.

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": {
      "execution_id": "<execution_id>",
      "expression": "<expression>"
    },
    "name": "evaluate_expression"
  }
}

Input Schema

Name	Required	Description	Default
`expression`	Yes	SpEL expression in ${...}, e.g. ${trigger.parameters.tag} or ${#stage('Deploy').status}
`execution_id`	Yes	Pipeline execution ID to evaluate against

Output Schema

Name	Required	Description	Default
`count`	No	Number of records in items.
`items`	No	The records, when Gate answered with a list.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.4.1Nov 1, 2026

changedInput schema / properties / expression / description

Previous value: -"SpEL expression string to evaluate"New value: +"SpEL expression in ${...}, e.g. ${trigger.parameters.tag} or ${#stage('Deploy').status}"

addedInput schema / properties / expression / maxLength
```
Added value: +4096
```

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"
+}

First observedv0.1.0Apr 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so safety is largely covered. The description adds genuinely useful context beyond them: a sandboxing constraint (reflection and class instantiation are blocked) that affects what expressions will succeed, which the agent cannot learn from annotations or schema.

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?

Four short sentences, front-loaded with the core action, then usage, then the security caveat, then return shape. No filler or repetition.

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?

With an output schema present and full parameter documentation plus annotations, the description needn't explain return values. It adds the security caveat and debugging framing, making it nearly complete; only error behavior (e.g., invalid expression, missing execution) is left implicit.

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 coverage is 100% and includes SpEL syntax examples (${trigger.parameters.tag}, ${#stage('Deploy').status}), so the schema carries the parameter burden. The description adds no additional meaning about expression format, escaping, or execution_id requirements.

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 (evaluate) and resource (SpEL expression) plus the evaluation context (pipeline execution), which is unique among siblings that are all get_/list_/find_/search_ retrieval tools. An agent can immediately tell this is an expression-evaluation tool, not a data-fetch tool.

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 inspect pipeline variables, stage outputs, or computed values during debugging" gives clear usage context and intent. It does not name exclusions or point to alternative tools (e.g., use get_execution instead when only static metadata is needed), so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.