Skip to main content
Glama
ttpears

GitLab MCP Server

by ttpears

Search Notes (Comments)

search_notes
Read-onlyIdempotent

Search full text of issue and merge request comments across GitLab globally, by project, or by group to find discussion details missed by general searches.

Instructions

Full-text search across issue and merge request comments. Scope can be global, a project, or a group. NOTE: on self-hosted GitLab, the "notes" search scope requires Advanced Search (Elasticsearch) to be enabled — without it, this endpoint returns an error. search_gitlab does NOT search note bodies; this tool does.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number. Default 1.
scopeNoSearch scope. Default global.global
searchYesSearch term. Trimmed; empty rejected.
perPageNoResults per page. Default 20.
groupPathNoRequired when scope=group. Full group path.
projectPathNoRequired when scope=project. Full project path.
userCredentialsNoYour GitLab credentials (optional — falls back to the configured env token if not provided)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
    • 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.15.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: the self-hosted GitLab requirement for Advanced Search/Elasticsearch and the error that results when it is absent. It doesn't discuss result caps or pagination behavior, but the prerequisite disclosure is the high-value item here.

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?

Three tight sentences with zero filler: capability first, scope second, the environment caveat and sibling distinction after. Nothing is repeated from annotations.

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?

With no output schema, the description would ideally hint at the return shape, but it fully covers prerequisites, scope semantics, and sibling differentiation for a read-only search tool. An agent has everything needed to invoke it correctly.

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 coverage is 100%, so all seven parameters including scope enum and conditional path requirements are already documented in structured form. The description reinforces scope choices but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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 ("Full-text search across issue and merge request comments") and immediately names the scope variants. The final clause distinguishes it from search_gitlab, so an agent can pick between the two without opening schemas.

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 routes agents away from search_gitlab when note bodies matter, and enumerates the three scope options with the required path params documented in the schema. It doesn't cover when to prefer get_notes over this search, but the primary alternative is handled clearly.

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