Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
cloud_infoA

Identify the cloud, region, and project these tools are pointed at, and report which operations are enabled.

list_serversA

List instances with their status and IP addresses. Optionally filter by status (e.g. ACTIVE, SHUTOFF) or by a name substring.

get_serverA

Full detail for one instance: flavor, image, key pair, security groups, addresses, and metadata.

list_flavorsA

List available flavors (instance sizes) with vCPU, RAM, and disk.

list_imagesA

List bootable images, optionally filtered by a name substring.

list_networksA

List networks available to this project, flagging which are external.

list_security_groupsB

List security groups and how many rules each contains.

list_keypairsA

List SSH key pairs registered in this project.

list_volumesA

List block storage volumes, their size, and what they are attached to.

get_quotasA

Report compute quota usage against limits: instances, vCPUs, and RAM.

check_capacityA

Check whether count instances of flavor fit inside the project's remaining quota, before attempting to create them.

get_console_outputA

Read the serial console log of an instance -- the fastest way to diagnose a VM that boots but is unreachable.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 12 tools

Disambiguation5/5

Each tool targets a distinct resource or check: servers, flavors, images, networks, security groups, keypairs, volumes, quotas, and console output. Even get_quotas and check_capacity are clearly separated by descriptions: one reports usage, the other tests fit before creation. There is no meaningful overlap or ambiguity.

Naming Consistency4/5

The vast majority of tools follow a clear list_<resource> or get_<resource> pattern, making the set predictable. The only outlier is cloud_info, which is a noun phrase rather than a verb_noun command, but it does not cause confusion.

Tool Count5/5

Twelve tools is well-scoped for an OpenStack inspection and capacity-planning server. Each tool covers a distinct resource or diagnostic operation, and none feel redundant or unnecessary. The count is appropriate for the apparent purpose.

Completeness3/5

The set provides solid read-only coverage of compute, storage, network, security, and quota resources, but it has notable dead ends: check_capacity implies instance creation, yet no create_server exists, and security groups only expose rule counts rather than actual rules. For broader OpenStack management workflows, lifecycle operations and deeper network/security-group details are missing.

Maintenance

ActivitySlowing
ResponsivenessNo issues