Skip to main content
Glama
Sign In
GitLab MCP Server

GitLab MCP Server

by ttpears
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Mark All Todos Done

mark_all_todos_done
DestructiveIdempotent

Mark pending GitLab to-do items as done for the authenticated user, optionally scoped by group, project, action, type, author, or target, and return the updated todos.

Instructions

Mark pending to-do items as done for the authenticated user. With no arguments, marks every pending todo. Optional scoping args (groupPath, projectPath, action, type, authorIds, targetId) narrow which todos are marked. Irreversible without per-item restore_todo calls. Returns the actual list of updated todos.

Input Schema

NameRequiredDescriptionDefault
typeNoLimit to todos targeting this type (e.g. Issue, MergeRequest, Epic).
actionNoLimit to todos with this action (e.g. assigned, mentioned, review_requested).
targetIdNoLimit to todos for a single target (e.g. a specific issue/MR GID).
authorIdsNoLimit to todos authored by these users. Numeric IDs or gid://gitlab/User/N strings.
groupPathNoLimit to a group by full path. Resolved to a node GID server-side.
projectPathNoLimit to a project by full path. Resolved to a node GID server-side.
userCredentialsNoYour GitLab credentials (optional — falls back to the configured env token if not provided)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / userCredentials / anyOf
      Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "accessToken": {
-        "minLength": 1,
-        "type": "string"
-      },
-      "gitlabUrl": {
-        "format": "uri",
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "properties": {
+      "accessToken": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "gitlabUrl": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Addedv1.19.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true; the description adds real value on top by warning the operation is 'Irreversible without per-item restore_todo calls' and by stating that the updated todos are returned. It does not contradict the annotations — marking done is consistent with both destructive and idempotent hints.

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

Conciseness5/5

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

Four short sentences, front-loaded with the action and the default no-args behavior before scoping and side effects. No filler; each sentence carries distinct information.

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?

Covers default behavior, scoping, irreversibility, and the return value in the absence of an output schema. The only gap is the shape of the returned todo list, which is a minor omission for a bulk mutation tool whose annotations already convey the safety profile.

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 every scoping parameter (type, action, targetId, authorIds, groupPath, projectPath) is already documented in the schema. The description only enumerates the parameter names and says they 'narrow which todos are marked', adding no syntax or resolution detail beyond what the schema provides — baseline 3.

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?

States a specific verb and resource ('Mark pending to-do items as done') plus the exact scope ('for the authenticated user'). The 'all' framing and the no-arguments behavior distinguish it from the singular mark_todo_done sibling without requiring a schema lookup.

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?

Explicitly describes the default mode ('With no arguments, marks every pending todo') and when to use the optional scoping args to narrow the set. It also points to restore_todo as the recovery path, though it never names mark_todo_done as the alternative for single-item marking — that is left to inference from the tool name.

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