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
list_pipeline_jobsA

List pipeline jobs, newest first. Optional filters: status (Active, Complete, Failed, Pending, or running), request_id, limit (default 50, max 100). Job names are pipelines-{request_id}-{step_index}-{replica}.

get_pipeline_jobB

Get one job by request_id, step_index, and replica.

list_pipeline_podsB

List pods for one job. Empty if they are already gone.

get_pipeline_job_configA

Get the full YAML config for one job by request_id, step_index, and replica. Secrets are redacted.

get_pipeline_podA

Get one pod by pod_name.

get_pipeline_pod_configA

Get the full YAML config for one pod by pod_name. Secrets are redacted.

get_pipeline_logA

Read pipeline worker logs for a request. Empty until the worker pod is running. Default is the last 100 lines plus a cursor. Pass cursor to get only new lines. full=true still caps size.

get_pipeline_service_logB

Read service logs for a request. Same cursor rules as pipeline log.

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 8 tools

Disambiguation5/5

Each tool has a clearly distinct resource/action pairing: jobs, pods, job configs, pod configs, and two log types. Pipeline worker logs and service logs are the only overlapping pair, but the names and descriptions cleanly separate them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using get_ or list_ prefixes. The resource nouns are uniform and predictable, with job/config/pod/log/service modifiers making the hierarchy easy to infer.

Tool Count5/5

Eight tools is a well-scoped size for a pipeline inspection server. Each tool covers a distinct need without redundancy or surface bloat.

Completeness4/5

The set provides solid read-only coverage of jobs, pods, configs, and logs, which matches an observability-focused purose. Minor gaps exist, such as no direct way to list services or aggregate request-level status, but agents can work around these using the existing list and get tools.

Maintenance

ActivityMaintained
ResponsivenessNo issues