Skip to main content
Glama
Sign In
spinnaker-mcp

spinnaker-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Remote

Get instance

get_instance
Read-onlyIdempotent

Retrieve details for a specific compute instance by account, region, and instance ID to inspect health, metadata, launch time, and cloud-specific attributes.

Instructions

Get details for a specific compute instance by account, region, and instance ID. Use this to inspect instance health, metadata, launch time, and cloud-specific attributes. Returns JSON with full instance details including health indicators.

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>",
      "instance_id": "<instance_id>"
    },
    "name": "get_instance"
  }
}

Input Schema

NameRequiredDescriptionDefault
regionYesCloud region (e.g. us-east-1)
accountYesSpinnaker account name
instance_idYesCloud provider instance ID (e.g., i-0abc1234def56789 for AWS)

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. Changed1 schema field changedv0.4.1
    • 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. Changed1 schema field changedv0.3.4
    • changedInput schema / properties / instance_id / description
      Previous value: -"Instance ID"New value: +"Cloud provider instance ID (e.g., i-0abc1234def56789 for AWS)"
  3. 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds only a light note that the response is JSON with health indicators, and says nothing about behavior on a missing instance or permission failures. Modest added value given rich 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, front-loaded with the identifying keys before the use case. The closing sentence about returning JSON is partially redundant now that an output schema exists, so it is not quite waste-free.

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 a full output schema and complete parameter descriptions, the description only needs to supply purpose and usage, which it does. The notable remaining gap is error behavior when the instance ID is unknown, a common case for a point lookup.

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% and all three required parameters carry their own descriptions, so the baseline is 3. The description merely restates that account, region, and instance ID identify the instance, adding no format or disambiguation detail beyond the schema.

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 details for a specific compute instance') and names the three identifying keys, which cleanly separates it from get_cluster, get_account, and the list_* siblings. It stops short of explicitly pointing at a sibling, but the resource noun is unambiguous.

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 instance health, metadata, launch time, and cloud-specific attributes' gives a concrete reason to call it rather than a vague one. No when-not conditions or alternatives (e.g., using list_server_groups to discover an instance ID) are offered, which keeps it out of 5 territory.

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