gitlab-api

Gitlab Ingest Pipelines

gitlab_ingest_pipelines

Ingest GitLab CI pipeline runs and their jobs into a knowledge graph as typed PipelineRun and CheckRun nodes, unifying GitLab CI/CD and GitHub Actions data for analysis.

Instructions

Natively ingest GitLab CI pipeline runs (+ jobs) into medulla.

Lists recent pipelines for project_id and pushes them as typed :PipelineRun/:CheckRun nodes (the same classes github-agent uses, so GitLab CI/CD and GitHub Actions unify) into the knowledge graph. Best-effort: returns {"ingested": None} when no engine is reachable. CONCEPT:AU-KG.ingest.enterprise-source-extractor.

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_id": "<project_id>"
    },
    "name": "gitlab_ingest_pipelines"
  }
}

Input Schema

Name	Required	Description
`ref`	No	Only pipelines on this ref.
`status`	No	Only pipelines with this status.
`per_page`	No	Pipelines per page.
`project_id`	Yes	GitLab project id or URL-encoded path to ingest recent pipeline runs for.
`include_jobs`	No	Also fetch + ingest each pipeline's jobs as :Job/:CheckRun nodes.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv27.3.20Nov 7, 2026

removedInput schema / properties / params_json

Removed value: -{
-  "default": "{}",
-  "description": "JSON string of get_pipelines filters (e.g. status, ref, per_page).",
-  "type": "string"
-}

addedInput schema / properties / per_page

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Pipelines per page."
+}

addedInput schema / properties / ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only pipelines on this ref."
+}

addedInput schema / properties / status

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only pipelines with this status."
+}

First observedv27.3.13Oct 25, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose real behavior: it writes :PipelineRun/:CheckRun nodes, fetches jobs by default, and is best-effort, returning {"ingested": None} when no engine is reachable. It omits idempotency (whether re-running duplicates nodes) and any volume/pagination bound on 'recent pipelines', which matter for a write-side tool.

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?

The ingest action and destination are front-loaded, and the node-class rationale is compact. The trailing 'CONCEPT:AU-KG.ingest.enterprise-source-extractor' tag is internal taxonomy noise that does not help an agent decide or call.

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?

There is no output schema, so the description appropriately explains the return shape and the degraded-engine case, plus the side effects on the graph. What remains uncovered — idempotency on repeat ingestion and how many pipelines 'recent' means — is the main gap for a tool that mutates a knowledge graph.

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 description coverage is 100%, so the baseline is 3. The description only echoes that jobs are included and that pipelines are scoped to project_id, adding little syntax or format meaning beyond what the schema already documents for ref, status, per_page, and include_jobs.

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 description names a specific verb and resource ('Natively ingest GitLab CI pipeline runs (+ jobs)') and a destination ('into medulla', 'knowledge graph'). It also names the exact node classes produced, which cleanly separates it from read-only siblings like gitlab_get_pipelines and from gitlab_ingest_projects.

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

Usage Guidelines4/5

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

The framing makes the use case clear: call this when you want pipeline data persisted into the knowledge graph rather than just retrieved. It does not explicitly name alternatives such as gitlab_get_pipelines or gitlab_ingest_projects, nor state exclusions, so it falls short of a 5.

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

Deploy Server