Skip to main content
Glama
Sign In
gitlab mcp

gitlab mcp

by zereight
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

search_repositories

Read-only

Search GitLab projects by query to find matching repositories. Use when a project identifier is unknown; use typed get or list tools once known.

Instructions

Search for GitLab projects. If the identifier is known, use a typed get or list tool.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_repositories"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (default 1)
queryNoSearch query (alias for 'search')
searchNoSearch query
jmespathNoOptional JMESPath expression filtering the JSON result before return.
per_pageNoItems per page (max 100, default 20)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.3.22
    • changedInput schema / properties / page / description
      Previous value: -"Page number for pagination (default: 1)"New value: +"Page number (default 1)"
    • changedInput schema / properties / per_page / description
      Previous value: -"Number of items per page (max: 100, default: 20)"New value: +"Items per page (max 100, default 20)"
  2. Changed1 schema field changedv2.1.66
    • addedInput schema / properties / jmespath
      Added value: +{
+  "description": "Optional JMESPath expression filtering the JSON result before return.",
+  "type": "string"
+}
  3. Addedv2.1.18
  4. Removedv2.1.14
  5. Addedv2.1.11
  6. Removedv2.1.10
  7. Changed3 schema fields changedv2.1.9
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / query
      Added value: +{
+  "description": "Search query (alias for 'search')",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "search"
-]
  8. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: no match behavior, no default result set size, no note that an empty result is normal for a search, and no pagination guidance despite page/per_page being present. With annotations doing the heavy lifting, a 3 is the right ceiling.

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?

Two sentences, front-loaded with the purpose and with zero filler or repetition. It is arguably under-sized rather than concise, which keeps it off a 5, but every sentence earns its place.

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?

Subtracting the schema (which fully documents all five parameters) and the annotations (read-only, open-world), the description covers the one thing structured fields cannot: how to choose the tool at all. It stops short of a 5 because scoping details, such as whether results span accessible projects only, are omitted for an open-world search.

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 most confusing aspect, that 'query' is an alias for 'search', is documented only in the schema, not the description, and the description adds no meaning about what the search string matches against.

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?

The first sentence states a specific verb and resource ('Search for GitLab projects'), which is clear enough to act on. It falls short of a 5 because it never says what field is searched (name, path, description) or how results differ from the sibling list_projects, so an agent still has to infer the distinction from the name alone.

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 second sentence gives an explicit routing rule: when the identifier is known, use a typed get or list tool instead. That is real when-to-use and when-not guidance naming an alternative path. It does not name the concrete siblings (get_project, list_projects) or cover the case where the identifier is only partially known.

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