Skip to main content
Glama

Get pipelines triggered from schedule

gitlab_get_pipelines_triggered_from_schedule
Read-onlyIdempotent

Retrieve pipelines triggered by a specific GitLab pipeline schedule using project and schedule IDs to inspect scheduled CI runs and their statuses.

Instructions

Get pipelines triggered from a specific pipeline schedule.

Args: **kwargs: Additional parameters for the request (e.g., project_id, pipeline_schedule_id).

Returns: Response: A wrapper containing the original response and a list of Pipeline models.

Raises: MissingParameterError: If the project_id or pipeline_schedule_id is missing. ParameterError: If invalid parameters are provided.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gitlab_get_pipelines_triggered_from_schedule"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNo
keyNo
refNo
cronNo
dataNo
nameNo
pageNo
pathNo
sortNo
tierNo
forceNo
limitNo
ownedNo
topicNo
valueNo
activeNo
avatarNo
beforeNo
mirrorNo
searchNo
simpleNo
statesNo
topicsNo
dry_runNo
starredNo
archivedNo
group_idNo
id_afterNo
importedNo
order_byNo
per_pageNo
tag_listNo
tag_nameNo
topic_idNo
id_beforeNo
max_pagesNo
expires_atNo
import_urlNo
membershipNo
project_idNo
statisticsNo
visibilityNo
descriptionNo
lfs_enabledNo
total_pagesNo
external_urlNo
group_accessNo
merge_methodNo
build_timeoutNo
cron_timezoneNo
public_buildsNo
squash_optionNo
variable_typeNo
approval_rulesNo
ci_config_pathNo
default_branchNo
environment_idNo
include_hiddenNo
mirror_user_idNo
emails_disabledNo
issues_templateNo
cluster_agent_idNo
environment_nameNo
min_access_levelNo
packages_enabledNo
allowed_to_createNo
auto_stop_settingNo
search_namespacesNo
wiki_access_levelNo
build_git_strategyNo
flux_resource_pathNo
pages_access_levelNo
repository_storageNo
auto_devops_enabledNo
builds_access_levelNo
ci_separated_cachesNo
create_access_levelNo
issues_access_levelNo
ci_default_git_depthNo
deploy_access_levelsNo
forking_access_levelNo
keep_latest_artifactNo
kubernetes_namespaceNo
merge_trains_enabledNo
pipeline_schedule_idNo
service_desk_enabledNo
merge_commit_templateNo
mirror_trigger_buildsNo
releases_access_levelNo
snippets_access_levelNo
analytics_access_levelNo
approvals_before_mergeNo
include_pending_deleteNo
mr_default_target_selfNo
request_access_enabledNo
shared_runners_enabledNo
squash_commit_templateNo
merge_pipelines_enabledNo
merge_requests_templateNo
operations_access_levelNo
repository_access_levelNo
requirements_access_levelNo
suggestion_commit_messageNo
repository_checksum_failedNo
auto_devops_deploy_strategyNo
autoclose_referenced_issuesNo
merge_requests_access_levelNo
auto_cancel_pending_pipelinesNo
ci_forward_deployment_enabledNo
enforce_auth_checks_on_uploadsNo
only_mirror_protected_branchesNo
allow_merge_on_skipped_pipelineNo
container_registry_access_levelNo
restrict_user_defined_variablesNo
remove_source_branch_after_mergeNo
resolve_outdated_diff_discussionsNo
mirror_overwrites_diverged_branchesNo
printing_merge_request_link_enabledNo
security_and_compliance_access_levelNo
only_allow_merge_if_pipeline_succeedsNo
container_expiration_policy_attributesNo
external_authorization_classification_labelNo
only_allow_merge_if_all_status_checks_passedNo
ci_allow_fork_pipelines_to_run_in_parent_projectNo
only_allow_merge_if_all_discussions_are_resolvedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv27.3.20
    • changedInput schema / properties / active / default
      Previous value: -trueNew value: +null
    • removedInput schema / properties / api_parameters
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "additionalProperties": true,
      -      "type": "object"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null
      -}
    • removedInput schema / properties / import_url / anyOf
      Removed value: -[
      -  {
      -    "format": "uri",
      -    "maxLength": 2083,
      -    "minLength": 1,
      -    "type": "string"
      -  },
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / import_url / title
      Added value: +"Import Url"
  2. First observedv27.3.13

TDQS

B3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real value beyond them: it reveals that project_id and pipeline_schedule_id are effectively mandatory (MissingParameterError otherwise) even though the schema marks nothing required, and it describes the return shape (wrapper containing a list of Pipeline models) plus the error types. It stops short of pagination or permission details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the Returns/Raises blocks are informative, but the 'Args: **kwargs' section is boilerplate that adds no usable information and is arguably misleading for a tool whose schema enumerates 125 concrete properties. Roughly a third of the text is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 125-parameter tool with no output schema and zero schema descriptions, the description explains almost nothing about the parameter surface an agent would face. It correctly captures the two essential ids and the return wrapper, but leaves the vast majority of the invoking surface undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 125 parameters, so the description carries the full burden and largely fails: the Args block is generic '**kwargs' boilerplate and names only project_id and pipeline_schedule_id as examples. An agent gets no signal about what the other 123 nullable properties mean or whether they are even relevant to this endpoint.

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 first sentence gives a specific verb ('Get') and resource ('pipelines triggered from a specific pipeline schedule'), which lets an agent separate it from gitlab_get_pipelines (all pipelines) and gitlab_get_pipeline_schedules (lists schedules). It never names those siblings explicitly, so differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this over gitlab_get_pipelines or gitlab_get_pipeline_schedule, and no mention of prerequisites such as needing the schedule to exist or permissions. The only context is the implicit requirement of a schedule id, which the Raises section hints at.

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

Deploy Server

Other Tools