Skip to main content
Glama

Get pipeline schedule

gitlab_get_pipeline_schedule
Read-onlyIdempotent

Retrieve details for a specific pipeline schedule in a GitLab project by providing the project ID and schedule ID, including cron, timezone, and active status.

Instructions

Get information about a specific pipeline schedule in a project.

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

Returns: Response: A wrapper containing the original response and a PipelineSchedule model.

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

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
api_parametersNo
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. First observedv27.3.13

TDQS

A3.6/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 safety profile is covered. The description adds useful value beyond annotations by disclosing the return wrapper ('original response and a PipelineSchedule model') and the specific errors raised (MissingParameterError, ParameterError).

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?

Front-loads the purpose sentence well, but the '**kwargs: Additional parameters for the request' line is generic filler that does little work given the schema. The Returns/Raises blocks are informative but the whole is a generic docstring template.

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

Completeness4/5

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

For a read-only getter whose annotations carry the safety profile, the description covers purpose, return shape, and required-parameter errors adequately. The unexplained bulk of 126 schema parameters is the main residual gap.

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

Parameters3/5

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

Schema has 126 params at 0% description coverage, so the description must carry weight. It does identify the two operative params (project_id, pipeline_schedule_id) and flags them as required via the MissingParameterError note, but leaves the remaining 124 parameters entirely unexplained, so compensation is partial.

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?

States a specific verb and resource ('Get information about a specific pipeline schedule in a project'), distinguishing it reasonably from the plural get_pipeline_schedules sibling via singular/plural naming. Doesn't explicitly call out the alternative, but the purpose is unambiguous.

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

Usage Guidelines3/5

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

Implies usage (fetch one specific schedule) but never states when to prefer this over gitlab_get_pipeline_schedules or gitlab_get_pipelines_triggered_from_schedule. No explicit when/when-not guidance or alternatives named.

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