spinnaker-mcp

Overview Schema Source Related Servers Discussions Admin

Get firewall

get_firewall

Read-onlyIdempotent

Retrieve a specific firewall rule (security group) by account, region, and name to inspect inbound/outbound rules and associated resources. Returns full rule set and metadata as JSON.

Instructions

Get details for a specific firewall rule (security group) by account, region, and name. Use this to inspect inbound/outbound rules and associated resources. Returns JSON with the firewall's full rule set and metadata.

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": {
      "account": "<account>",
      "region": "<region>",
      "name": "<name>"
    },
    "name": "get_firewall"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Firewall rule name
`region`	Yes	Cloud region (e.g. us-east-1)
`vpc_id`	No	VPC ID, to tell apart AWS security groups with the same name (e.g. vpc-0abc123)
`account`	Yes	Spinnaker account name
`provider`	No	Cloud provider of the account (default aws, as in Gate; e.g. gce, azure, kubernetes)	aws

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

addedInput schema / properties / provider

Added value: +{
+  "default": "aws",
+  "description": "Cloud provider of the account (default aws, as in Gate; e.g. gce, azure, kubernetes)",
+  "type": "string"
+}

addedInput schema / properties / vpc_id

Added value: +{
+  "description": "VPC ID, to tell apart AWS security groups with the same name (e.g. vpc-0abc123)",
+  "type": "string"
+}

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

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds little beyond confirming the lookup is keyed by account/region/name and noting that the response contains the rule set; it does not mention errors when the rule is absent or ambiguity handling when names collide across VPCs (that only appears in the schema).

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 core identity and then usage context front-loaded; no filler. The closing sentence about JSON return is mildly redundant given an output schema exists.

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 annotations covering safety, a full output schema, and 100% parameter descriptions, the description supplies what an agent needs to select and call it. Missing only explicit sibling routing (list_firewalls for enumeration) and not-found behavior.

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%, so all five parameters including provider default and vpc_id disambiguation are already documented. The description merely restates the three required keys and adds no format or edge-case semantics, making baseline 3 appropriate.

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 (get) and resource (a specific firewall rule / security group) plus the three identifying keys, and the term 'specific' implicitly separates it from list_firewalls. It does not explicitly name the sibling, so differentiation is inferable rather than stated.

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 inbound/outbound rules and associated resources' gives a clear usage context for a lookup-by-identity call. There is no when-not guidance or explicit pointer to list_firewalls for enumeration, so it stops short of full routing guidance.

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