Skip to main content
Glama
call518

MCP-OpenStack-Ops

by call518

get_instance

Query OpenStack instances by ID, name, status, or search fields to view details, list resources, and paginate results for status checks and instance searches.

Instructions

Unified instance query tool supporting all instance retrieval patterns. Consolidates functionality from get_instance_details, get_instance_by_name, get_instances_by_status, and search_instances.

Functions:

  • Get specific instances by names or IDs

  • Filter instances by status (ACTIVE, SHUTOFF, ERROR, etc.)

  • Search instances across multiple fields (name, flavor, image, host, etc.)

  • List all instances with pagination

  • Support both summary and detailed information modes

Use when user requests instance information, status checks, or instance searches.

Input Schema

NameRequiredDescriptionDefault
idsNoSpecific instance ID(s) to retrieve (comma-separated)
limitNoMaximum instances to return (default: 50, max: 200)
namesNoSpecific instance name(s) to retrieve (comma-separated: "vm1,vm2,vm3")
offsetNoNumber of instances to skip for pagination
statusNoFilter by instance status (e.g., "ACTIVE", "SHUTOFF", "ERROR")
detailedNoIf True, return detailed information; if False, return summary only
search_inNoFields to search in ("name", "status", "host", "flavor", "image", "availability_zone", "all")name
search_termNoSearch term for partial matching across fields
all_instancesNoIf True, retrieve all instances (ignores other filters)
case_sensitiveNoCase-sensitive search (default: False)

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv3.5.8
    • addedInput schema / properties / all_instances / description
      Added value: +"If True, retrieve all instances (ignores other filters)"
    • addedInput schema / properties / case_sensitive / description
      Added value: +"Case-sensitive search (default: False)"
    • addedInput schema / properties / detailed / description
      Added value: +"If True, return detailed information; if False, return summary only"
    • addedInput schema / properties / ids / description
      Added value: +"Specific instance ID(s) to retrieve (comma-separated)"
    • addedInput schema / properties / limit / description
      Added value: +"Maximum instances to return (default: 50, max: 200)"
    • addedInput schema / properties / names / description
      Added value: +"Specific instance name(s) to retrieve (comma-separated: \"vm1,vm2,vm3\")"
    • addedInput schema / properties / offset / description
      Added value: +"Number of instances to skip for pagination"
    • addedInput schema / properties / search_in / description
      Added value: +"Fields to search in (\"name\", \"status\", \"host\", \"flavor\", \"image\", \"availability_zone\", \"all\")"
    • addedInput schema / properties / search_term / description
      Added value: +"Search term for partial matching across fields"
    • addedInput schema / properties / status / description
      Added value: +"Filter by instance status (e.g., \"ACTIVE\", \"SHUTOFF\", \"ERROR\")"
  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?

With no annotations, the description carries the full behavioral burden. It discloses supported retrieval modes, pagination, and summary/detailed output, but does not state that the operation is read-only, how multiple filters interact, or any permission/rate-limit considerations.

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?

The description is front-loaded with its unified purpose and then lists concrete supported functions. It is efficient overall, though the function list and final usage sentence have some overlap.

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?

Given 100% schema coverage and an output schema, the description does not need to explain return values. It adequately summarizes the main retrieval patterns for a ten-parameter tool, though it could clarify filter precedence and the relationship to duplicate sibling tools.

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 the schema already documents all ten parameters. The description adds useful pattern-level grouping (by names/IDs, status, search fields, pagination), but does not add syntax, precedence, or combination semantics beyond what the schema provides.

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?

The description states a specific resource and verb ('Unified instance query tool') and enumerates retrieval patterns it supports. It also names the sibling tools whose functionality it consolidates, which helps distinguish it, though those siblings still appear as separate tools and no explicit selection rule is given.

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?

It gives a clear usage condition: 'Use when user requests instance information, status checks, or instance searches.' However, it does not explicitly say when to use this consolidated tool versus the still-present specialized siblings such as get_instance_details or search_instances.

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