Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MCP_HOSTNoHost to bind for HTTP transport, default 0.0.0.00.0.0.0
MCP_PORTNoPort for HTTP transport, default 87658765
GITLAB_URLNoGitLab instance URL, e.g. https://gitlab.example.com
JENKINS_URLYesJenkins base URL, e.g. https://jenkins.example.com
GITLAB_TOKENNoGitLab access token with read_api; falls back to token in ~/.claude.json if unset
JENKINS_USERYesJenkins username
JENKINS_TOKENYesJenkins API token (not your password)
MCP_TRANSPORTNoTransport mode: stdio (default) or streamable-httpstdio
GITLAB_PROJECTNoGitLab project path, e.g. your-group/your-project
MCP_AUTH_TOKENNoShared bearer token for HTTP endpoint; set when running HTTP to avoid unauthenticated access
JENKINS_MCP_CONFIGNoPath to job mapping config file, defaults to ./config.json./config.json

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_jobsA

List Jenkins jobs. Pass folder (e.g. 'team/sub') to scope; empty lists root.

get_job_infoA

Get details about a job: description, parameters (with defaults), last build numbers, health.

trigger_buildA

Trigger a build with raw Jenkins parameter names.

If wait=True (default), polls the queue until a build number is assigned. For a higher-level deploy with friendly names (branch, tickets…), use deploy().

get_queue_itemA

Poll a single queue item URL — returned by trigger_build / deploy when wait=False.

wait_for_buildA

Block polling a queue URL until a build number is assigned (or timeout).

get_build_infoB

Full info about a specific build: result, timestamp, duration, parameters, git.

get_build_logB

Console output for a build. Returns the last tail_lines lines by default.

list_recent_buildsB

List recent builds for a job with timestamps, durations, and results.

get_last_successful_buildA

Last SUCCESSFUL build with timestamp, duration, parameters, and git info.

Primary use case: compare timestamp vs a GitLab MR merge time to verify deployment.

get_queueA

List items currently waiting in the build queue.

is_deployed_sinceA

Check whether the job's last successful build ran AFTER a given ISO timestamp.

Intended for: "was this GitLab MR (merged at ) deployed?" Accepts ISO 8601 like '2026-04-24T10:15:00+00:00' or '2026-04-24T10:15:00Z'.

list_deploymentsA

List deployment-type jobs grouped by environment, with last build time + status.

Use this to discover what you can deploy. Returns groups: dev, stage, automation, utility, other.

resolve_job_nameA

Given a rough name ('dev backend'), show the matched job and close candidates.

deployA

High-level deploy. Maps friendly args to the job's actual Jenkins parameters.

Args: job: Deploy target (fuzzy). A bare environment defaults to the configured app job: 'dev' / 'deploy dev' → 'dev_app_deployment'; say 'dev backend' for the backend job. Other job names resolve by fuzzy match. branch: Git branch to deploy. Sets whichever branch parameter the job defines (see config). tickets: Ticket URL(s) for the deployment purpose. Multiple URLs may be passed comma-separated ('url1, url2'); they are normalized to a comma-joined list. install_dependencies: If True, sets INSTALL_BE_REQUIREMENTS + INSTALL_FE_PACKAGES (whichever exist). use_server_secrets: Sets USE_SECRETS_FROM_SERVER. config_branch: Sets CONFIGURATION_MANAGEMENT_BRANCH. Default is already 'main' on most jobs. use_dummy_purpose: When the job mandates a deployment purpose and the user has no ticket URL, set this True to deploy with the placeholder purpose (<configured dummy_purpose>). Leave False to be told the purpose is required. allow_mr_purpose: Set True to accept a merge-request URL as the purpose after the user confirms (see the 'mr_url_as_purpose' guard below). extra: Raw Jenkins param overrides {name: value}. Used for anything the friendly API misses. wait: Poll the queue until a build number is assigned. timeout: Max seconds to wait for the queue→build transition.

Mandatory deployment purpose: if the resolved job enforces a non-empty purpose (DEPLOYMENT_PURPOSE) and no tickets was given, this returns {"error": "deployment_purpose_required", ...} WITHOUT deploying. When you get that, ask the user whether to (a) paste a ticket/URL — then re-call with tickets=... — or (b) proceed with a dummy URL — then re-call with use_dummy_purpose=True.

Merge-request URL guard: the purpose should be ticket URL(s). If any supplied URL is a merge request (/merge_requests/<id>) this returns {"error": "mr_url_as_purpose", ...} WITHOUT deploying. Tell the user the URL is an MR, not a ticket, and ask them to either paste the correct ticket URL or re-call with allow_mr_purpose=True to proceed anyway.

Returns the trigger result with build_number, build_url, and parameters_sent.

deploy_ticketsA

One-shot deploy by ticket URL(s) + environment.

Use when the user says things like:

  • "deploy on dev"

  • "deploy , to stage"

  • "deploy on dev backend"

Args: tickets: Ticket URL, or multiple URLs (comma, semicolon, or whitespace-separated). environment: 'dev' / 'stage' (aliases: 'development', 'staging', 'stg'). scope: 'app' (combined FE+BE, default) or 'backend' (backend-only). branch: Optional git branch override. If omitted, Jenkins uses the job's default ('dev' for dev jobs, 'stage' for stage jobs). install_dependencies: Optional override for INSTALL_BE_REQUIREMENTS / INSTALL_FE_PACKAGES. wait: Poll the queue until a build number is assigned. timeout: Max seconds to wait for the queue→build transition.

get_ticket_mrsA

Find MRs linked to a ticket URL (matched in MR title/description).

Args: ticket_url: Full URL of the GitLab ticket/issue. state: 'all' | 'opened' | 'merged' | 'closed'. Default 'all'.

is_ticket_deployedA

Verify whether a ticket's merged MRs are deployed on dev or stage.

For each merged MR:

  • classifies files as frontend (frontend/, .scss/.css outside static/) or backend (static/**, requirements/, apps/, common/, hrdb/**, *.py)

  • checks if the MR's merge commit was an ancestor of the deployed branch at the time the relevant Jenkins build ran:

    • FE changes: only <env>_app_deployment can cover

    • BE changes: <env>_app_deployment or <env>_backend_deployment

  • reports per-MR deployed=true/false with reasons

Overall ticket is "deployed" only when every merged MR is fully covered. Un-merged MRs are reported separately.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 17 tools

Disambiguation3/5

Most tools target distinct resources, but there is real overlap among queue-related tools (get_queue_item vs wait_for_build vs get_queue) and deploy helpers (deploy vs deploy_tickets vs trigger_build). The detailed descriptions help disambiguate, but some tools could still be confusing to an agent.

Naming Consistency4/5

Tool names use consistent snake_case and mostly follow a verb_noun pattern: list_* and get_* for reads, trigger_build, deploy, resolve_job_name for actions. The mix of list/get and imperative verbs is minor and still predictable.

Tool Count4/5

17 tools is slightly above the ideal 3-15 range, but the count is justified by combining core Jenkins introspection with deployment-specific and ticket-verification workflows. Each tool has a reasonably distinct niche.

Completeness4/5

The toolset covers job discovery, build triggering, queue monitoring, build results, logs, deployment configuration, and ticket-based deployment verification. Minor gaps such as cancel/abort build or job CRUD exist, but the core CI/CD and deployment workflows are well covered.

Maintenance

ActivitySlowing
ResponsivenessNo issues