gitlab-ci-mcp

Overview Schema Source Related Servers Discussions Admin

gitlab_pipeline_health

Read-onlyIdempotent

Aggregate pipeline success rates over 7 and 30 days with a trend indicator to assess branch stability for stand-ups and on-call hand-offs.

Instructions

Aggregate success rate over 7 and 30 days with a trend indicator.

Great for stand-ups and on-call hand-offs. Returns success rate %, totals, last-10 statuses and a trend (up/down/flat).

Emits progress via the MCP Context (info log + report_progress) — useful in IDEs that show per-tool progress bars.

Examples: - "How stable is master" → default (ref='master', source='schedule') - "Push-driven pipeline health" → source='push' - Don't use for a single pipeline — use gitlab_get_pipeline.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_path": "<project_path>"
    },
    "name": "gitlab_pipeline_health"
  }
}

Input Schema

Name	Required	Description	Default
`ref`	No	Branch to analyse.	master
`source`	No	Pipeline source to include (typically 'schedule' or 'push').	schedule
`project_path`	Yes	GitLab project path (e.g. 'my-org/my-repo'). Required by default. For legacy deployments only, set GITLAB_ALLOW_DEFAULT_PROJECT=true to use GITLAB_PROJECT_PATH when omitted.

Output Schema

Name	Required	Description	Default
`ref`	Yes
`trend`	Yes
`source`	Yes
`status`	Yes
`project`	Yes
`rate_7d`	Yes
`rate_30d`	Yes
`total_7d`	Yes
`failed_7d`	Yes
`total_30d`	Yes
`failed_30d`	Yes
`rate_basis`	Yes
`success_7d`	Yes
`success_30d`	Yes
`completed_7d`	Yes
`generated_at`	Yes
`completed_30d`	Yes
`last_10_statuses`	Yes
`insufficient_data`	Yes
`invalid_timestamps`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv0.5.5Nov 5, 2026

removedInput schema / properties / project_path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / project_path / default
```
Removed value: -null
```

changedInput schema / properties / project_path / description

Previous value: -"GitLab project path (e.g. 'my-org/my-repo'). When omitted, the default from GITLAB_PROJECT_PATH env var is used."New value: +"GitLab project path (e.g. 'my-org/my-repo'). Required by default. For legacy deployments only, set GITLAB_ALLOW_DEFAULT_PROJECT=true to use GITLAB_PROJECT_PATH when omitted."

addedInput schema / properties / project_path / minLength
```
Added value: +1
```
addedInput schema / properties / project_path / type
```
Added value: +"string"
```
addedInput schema / required
```
Added value: +[
+  "project_path"
+]
```

addedOutput schema / properties / completed_30d

Added value: +{
+  "title": "Completed 30D",
+  "type": "integer"
+}

addedOutput schema / properties / completed_7d

Added value: +{
+  "title": "Completed 7D",
+  "type": "integer"
+}

addedOutput schema / properties / insufficient_data

Added value: +{
+  "title": "Insufficient Data",
+  "type": "boolean"
+}

addedOutput schema / properties / invalid_timestamps

Added value: +{
+  "title": "Invalid Timestamps",
+  "type": "integer"
+}

addedOutput schema / properties / rate_30d / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / rate_30d / type
```
Removed value: -"number"
```

addedOutput schema / properties / rate_7d / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / rate_7d / type
```
Removed value: -"number"
```

addedOutput schema / properties / rate_basis

Added value: +{
+  "title": "Rate Basis",
+  "type": "string"
+}

addedOutput schema / properties / status

Added value: +{
+  "title": "Status",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "project",
-  "ref",
-  "source",
-  "rate_7d",
-  "rate_30d",
-  "trend",
-  "total_7d",
-  "success_7d",
-  "failed_7d",
-  "total_30d",
-  "success_30d",
-  "failed_30d",
-  "last_10_statuses",
-  "generated_at"
-]New value: +[
+  "project",
+  "ref",
+  "source",
+  "rate_7d",
+  "rate_30d",
+  "trend",
+  "total_7d",
+  "completed_7d",
+  "success_7d",
+  "failed_7d",
+  "total_30d",
+  "completed_30d",
+  "success_30d",
+  "failed_30d",
+  "last_10_statuses",
+  "generated_at",
+  "status",
+  "invalid_timestamps",
+  "insufficient_data",
+  "rate_basis"
+]

First observedv0.5.1Apr 17, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses that the tool emits progress via the MCP Context (info log + report_progress) for IDE progress bars — a behavioral trait annotations cannot express. It also notes the fixed 7/30-day windows, though it says nothing about behavior with sparse pipeline history or API failure modes.

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

Conciseness4/5

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

Purpose is front-loaded, then use cases, then examples, then the explicit exclusion — a clean information hierarchy with no filler. The one soft spot is enumerating return fields (success rate %, totals, last-10 statuses, trend) that the output schema already carries.

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 aggregate tool with full annotation coverage, an output schema, and fully described parameters, the description supplies everything needed to select and call it. Minor gaps remain around behavior on projects with short history or empty pipeline sets, but nothing blocking.

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

Parameters4/5

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

Schema coverage is already 100% and documents defaults and the source enum, so the baseline is 3. The description adds real semantic value by mapping intent to parameters ('How stable is master' → default ref='master', source='schedule'; 'Push-driven pipeline health' → source='push'), which tells the agent how the defaults are meant to be interpreted in practice.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('Aggregate success rate over 7 and 30 days with a trend indicator') and the closing line explicitly excludes the sibling gitlab_get_pipeline. An agent can separate this from gitlab_list_pipelines and gitlab_get_pipeline_jobs without opening any schema.

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

Usage Guidelines5/5

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

It states when the tool shines ('Great for stand-ups and on-call hand-offs'), gives two concrete query-to-parameter mappings, and states when NOT to use it ('Don't use for a single pipeline — use gitlab_get_pipeline'). The alternative is named with the condition that selects it.

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