Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ZUUL_URLYesZuul base URL (e.g. https://softwarefactory-project.io/zuul)
ZUUL_TIMEOUTNoHTTP timeout in seconds30
ZUUL_AUTH_TOKENNoBearer token for authenticated instances
ZUUL_VERIFY_SSLNoSSL certificate verificationtrue
ZUUL_USE_KERBEROSNoEnable Kerberos/SPNEGO authenticationfalse
ZUUL_DEFAULT_TENANTNoDefault tenant (saves passing tenant on every call)

Capabilities

Features and capabilities supported by this server

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

Tools

Functions exposed to the LLM to take actions

NameDescription
list_builds

Search builds with filters. Returns compact build summaries.

Args: tenant: Tenant name (uses default if empty) project: Filter by project name pipeline: Filter by pipeline name job_name: Filter by job name change: Filter by change number branch: Filter by branch name patchset: Filter by patchset ref: Filter by git ref result: Filter by result (SUCCESS, FAILURE, TIMED_OUT, SKIPPED, etc.) completed_after: Filter builds completed after this time (ISO 8601, e.g. "2026-04-18T00:00:00Z") completed_before: Filter builds completed before this time (ISO 8601) started_after: Filter builds started after this time (ISO 8601) started_before: Filter builds started before this time (ISO 8601) limit: Max results, 1-100 (default 20) skip: Offset for pagination (default 0)

get_build

Get full build details — log URL, nodeset, artifacts, timing, error detail.

Args: uuid: Build UUID (full or prefix from list_builds) tenant: Tenant name (uses default if empty) url: Zuul build URL (alternative to uuid + tenant, e.g. "https://zuul.example.com/t/tenant/build/abc123")

get_build_failures

Analyze a failed build — returns exactly which task failed, on which host, with error message and return code.

Parses Zuul's structured job-output.json for precise failure data. For most use cases, prefer diagnose_build which includes all this data plus failure classification, log context, and timing details.

Failure responses include ref_url/project/change and files_in_failure (file paths extracted from error output). Use these to check whether failing files are part of the change before concluding if a failure is change-related or a pre-existing repo issue.

Args: uuid: Build UUID tenant: Tenant name (uses default if empty) url: Zuul build URL (alternative to uuid + tenant)

diagnose_build

One-call failure diagnosis — structured failures + relevant log context.

Combines get_build_failures (which task failed, error message) with targeted log grep (surrounding context from job-output.txt). Returns everything needed to understand a failure in a single call.

Includes ref_url/project/change and files_in_failure so consumers can check whether failing files are part of the change or pre-existing.

Use this instead of calling get_build_failures + get_build_log separately.

Args: uuid: Build UUID tenant: Tenant name (uses default if empty) url: Zuul build URL (alternative to uuid + tenant)

list_buildsets

Search buildsets (groups of builds triggered by a single event).

Args: tenant: Tenant name (uses default if empty) project: Filter by project pipeline: Filter by pipeline name change: Filter by change number branch: Filter by branch name ref: Filter by git ref result: Filter by result completed_after: Filter buildsets completed after this time (ISO 8601, e.g. "2026-04-18T00:00:00Z") completed_before: Filter buildsets completed before this time (ISO 8601) started_after: Filter buildsets started after this time (ISO 8601) started_before: Filter buildsets started before this time (ISO 8601) limit: Max results, 1-100 (default 20) skip: Offset for pagination include_builds: Fetch full details (builds, events) for each buildset. Saves a separate get_buildset call per result, but slower for large result sets. Best with limit <= 5.

get_buildset

Get full buildset details — all builds, results, events, and timing.

Args: uuid: Buildset UUID tenant: Tenant name (uses default if empty) url: Zuul buildset URL (alternative to uuid + tenant)

list_jobs

List all jobs in a tenant. Optionally filter by name substring.

Args: tenant: Tenant name (uses default if empty) filter: Case-insensitive substring to filter job names limit: Max results to return (default 200, 0 for unlimited)

get_job

Get job configuration — parent, nodeset, timeout, branches, and all variants.

Args: name: Job name tenant: Tenant name (uses default if empty)

get_project

Get project configuration — which pipelines and jobs are configured.

Args: name: Project name (e.g. "openstack-k8s-operators/openstack-operator") tenant: Tenant name (uses default if empty)

list_pipelines

List all pipelines with their trigger types.

Args: tenant: Tenant name (uses default if empty)

get_config_errors

Get Zuul configuration errors — why jobs aren't running, broken configs, missing refs.

This is the first tool to check when a job isn't being triggered or a project has unexpected behavior. Returns syntax errors, missing references, and repo access issues for the tenant or a specific project.

Args: tenant: Tenant name (uses default if empty) project: Filter to a specific project name (optional)

list_projects

List all projects in a tenant. Optionally filter by name substring.

Args: tenant: Tenant name (uses default if empty) filter: Case-insensitive substring to filter project names limit: Max results to return (default 200, 0 for unlimited)

list_nodes

List nodepool nodes — shows what's available, in-use, or being provisioned.

Check this when jobs are stuck waiting for nodes. By default returns a summary grouped by label and state. Set detail=true for individual nodes.

Args: tenant: Tenant name (uses default if empty) detail: Include individual node list (default false, summary only) limit: Max nodes in detail list (default 200, 0 for unlimited). Summary stats always cover all nodes regardless of limit.

list_labels

List available nodepool labels (node types that jobs can request).

Args: tenant: Tenant name (uses default if empty)

list_semaphores

List semaphores — resource locks that limit concurrent job execution.

Check this when jobs are waiting unexpectedly. A semaphore at max holders means jobs are queued waiting for the lock to be released.

Args: tenant: Tenant name (uses default if empty)

list_autoholds

List autohold requests — nodes held after failure for debugging.

Shows active autohold requests: which project/job/change triggered them, how many nodes are held, and expiration.

Args: tenant: Tenant name (uses default if empty)

get_freeze_jobs

Get the resolved job graph for a pipeline/project/branch.

Shows exactly which jobs will run with all inheritance resolved, including dependencies between jobs. Use this to understand job ordering and why a job is (or isn't) in a pipeline.

Args: pipeline: Pipeline name (e.g. "check", "gate") project: Project name (e.g. "openstack-k8s-operators/openstack-operator") branch: Branch name (default "main") tenant: Tenant name (uses default if empty)

get_connections

List configured source connections — Gerrit, GitHub, GitLab instances.

Shows what code review systems this Zuul instance talks to, with connection type, hostname, and base URL.

get_components

Show Zuul system components — schedulers, executors, mergers, web servers.

Check this to see if Zuul is healthy. Shows component state (running/paused), version, and hostname.

get_freeze_job

Get the fully-resolved configuration for a specific job after inheritance.

Shows the final merged nodeset, timeout, playbooks, and variables after all parent job inheritance is applied. Use this to understand exactly what a job will do — resolves "what nodeset will it use?" and "which playbooks run?" questions.

Args: pipeline: Pipeline name (e.g. "check", "gate") project: Project name (e.g. "openstack-k8s-operators/openstack-operator") job_name: Job name to resolve branch: Branch name (default "main") tenant: Tenant name (uses default if empty)

get_tenant_info

Get tenant capabilities, auth config, and websocket URL.

Shows what features are available for this tenant (job history, auth realms) and the tenant name.

Args: tenant: Tenant name (uses default if empty)

stream_build_console

Read live console output from a RUNNING build.

Connects to Zuul's WebSocket console-stream endpoint and captures output for timeout seconds, returning the last lines lines (tail behavior). This tool is for RUNNING builds only. For completed builds, use tail_build_log or get_build_log instead.

Optional — requires pip install mcp-zuul[console].

Args: uuid: Build UUID (from get_change_status) tenant: Tenant name (uses default if empty) url: Zuul build URL (alternative to uuid + tenant) lines: Number of lines to return from the end (default 100, max 500) timeout: Seconds to buffer before returning (default 10, max 30)

get_build_anomalies

Detect anomalous log lines using LogJuicer ML-based analysis.

Compares failed build logs against successful baselines to find lines that are unusual. Requires LOGJUICER_URL to be configured. Accepts a build UUID or Zuul build URL.

Args: uuid: Build UUID tenant: Tenant name (uses default if empty) url: Zuul build URL (alternative to uuid + tenant)

get_build_log

Read, search, and navigate build log files with grep, line ranges, and error summary.

Args: uuid: Build UUID tenant: Tenant name (uses default if empty) log_name: Log file to read (default "job-output.txt"). For other files, use the path relative to the build's log_url, e.g. "logs/controller/ci-framework-data/logs/ci_script_008_run.log" mode: "summary" (default: tail + error lines) or "full" (paginated chunks) lines: For summary: tail line count (default 100). For full: offset start line. start_line: Read from this line number (1-based). If set with end_line, returns exactly that range (overrides mode). end_line: Read up to this line number (1-based, inclusive). grep: Python regex pattern to filter log lines (overrides mode). Use | for OR: "error|failed|timeout". Do NOT use backslash-pipe. context: Lines of context before/after each grep match (default 0, max 10) url: Zuul build URL (alternative to uuid + tenant)

browse_build_logs

Browse or fetch files from a build's log directory.

Without path: lists the top-level log directory. With path ending in '/': lists that subdirectory. With path to a file: fetches and returns the file content (max 512KB).

For filtered reads of large files, use get_build_log with log_name and grep instead — it supports regex search and line ranges.

Args: uuid: Build UUID tenant: Tenant name (uses default if empty) path: Relative path within the log dir (e.g. "logs/controller/", "zuul-info/inventory.yaml", "logs/hypervisor/ci-framework-data/artifacts/") url: Zuul build URL (alternative to uuid + tenant) max_lines: Limit file content to first N lines (0 = no limit). Response includes total_lines count for pagination.

tail_build_log

Get the last N lines of a build log — fastest way to see why a build failed.

More token-efficient than get_build_log(mode="summary") when you just need the tail. Use this as the first step when investigating failures.

Args: uuid: Build UUID tenant: Tenant name (uses default if empty) lines: Number of lines from the end (default 50, max 500) log_name: Log file to read (default "job-output.txt") url: Zuul build URL (alternative to uuid + tenant) skip_postrun: Skip post-run log collection lines and tail from the end of the run phase instead (default true). Only applies to job-output.txt. Set false to see raw tail.

list_tenants

List all Zuul tenants with project and queue counts.

get_status

Live pipeline status showing what's currently queued/running.

Args: tenant: Tenant name (uses default if empty) pipeline: Filter to a specific pipeline name project: Filter to a specific project active_only: Only show pipelines with active items (default true)

get_change_status

Pipeline status for a specific Gerrit change or GitHub/GitLab PR/MR.

When the change is in the pipeline, returns live status with jobs, elapsed times, and buildset UUID. When not in pipeline, automatically fetches the latest completed buildset with all build results — no extra list_buildsets + get_buildset round-trips needed.

Args: change: Change number (e.g. "12345"), GitHub ref ("refs/pull/123/head"), or GitLab ref ("refs/merge-requests/123/head") tenant: Tenant name (uses default if empty) url: Zuul change status URL (alternative to change + tenant) brief: Strip response to monitoring essentials (default false). Omits log_url, artifacts, stream_url, dependencies, and other static fields that don't change between polls. Use this for repeated status checks to reduce token consumption by ~75%.

find_flaky_jobs

Detect flaky jobs by analyzing recent build history for intermittent failures.

Fetches recent builds for a job and computes pass/fail statistics. A job with mixed SUCCESS/FAILURE results and >20% failure rate is likely flaky. Returns per-result counts and the failure rate.

Args: job_name: Job name to analyze tenant: Tenant name (uses default if empty) project: Filter to a specific project pipeline: Filter to a specific pipeline limit: Number of recent builds to analyze (default 20, max 100)

get_build_times

Build duration trends — is a job getting slower? Compute avg/min/max from results.

Returns build durations with timing data for trend analysis. Use this to detect performance regressions or timeout-prone jobs.

Note: This endpoint returns ALL results (SUCCESS, FAILURE, etc.) and does not support result filtering. For filtered averages (e.g. SUCCESS-only), use get_job_durations instead.

Args: tenant: Tenant name (uses default if empty) job_name: Filter by job name project: Filter by project name pipeline: Filter by pipeline name branch: Filter by branch name limit: Max results, 1-100 (default 20) skip: Offset for pagination

get_job_durations

Get avg/min/max duration for multiple jobs in a single call.

Fetches build history for each job in parallel and computes duration statistics. Designed for monitoring tools that need avg durations for an entire pipeline chain without making N separate API calls.

Args: job_names: List of job names to get stats for tenant: Tenant name (uses default if empty) result: Filter by result (default "SUCCESS" for clean averages) limit: Builds per job to analyze (default 10, max 50)

get_build_test_results

Parse JUnit XML test results from a build's log directory.

Discovers test result files via zuul-manifest.json and parses JUnit XML to return structured pass/fail/skip counts with failure details. Works with tempest, tobiko, and any test framework that produces JUnit XML output.

Args: uuid: Build UUID tenant: Tenant name (uses default if empty) url: Zuul build URL (alternative to uuid + tenant)

Prompts

Interactive templates invoked by user choice

NameDescription
debug_buildInvestigate a CI build failure - pre-loads build details and structured failures.
compare_buildsCompare two builds side-by-side - highlights differences in result, timing, nodeset, and failures.
check_changeCheck the current CI status of a change - live pipeline or latest results.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/imatza-rh/mcp-zuul'

If you have feedback or need assistance with the MCP directory API, please join our Discord server