Skip to main content
Glama
Sign In
mcp-gitlab-crunchtools

mcp-gitlab-crunchtools

by crunchtools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List Projects Tool

list_projects_tool
Read-only

List GitLab projects accessible by API token, with search, visibility, ownership, membership filters, sorting, and pagination controls.

Instructions

List GitLab projects accessible by the API token.

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": "list_projects_tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number for pagination (default: 1)
sortNoSort direction (asc, desc)desc
ownedNoOnly list projects owned by the authenticated user
searchNoSearch for projects by name
order_byNoOrder by field (created_at, updated_at, name, path)created_at
per_pageNoResults per page, max 100 (default: 20)
membershipNoOnly list projects the user is a member of
visibilityNoFilter by visibility (public, internal, private)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safe read-only nature is covered structurally. The description adds only that results are limited to what the token can access, which is useful scope context but does not mention pagination limits, default page size, or result volume. With annotations carrying the safety profile, this is adequate but thin.

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?

A single efficient sentence with no filler. It is front-loaded but arguably under-specified rather than truly concise, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, return values need not be explained, and the schema fully covers inputs. Still, for an 8-parameter paginated listing tool, the description says nothing about pagination behavior or filtering capabilities, leaving an agent to infer it all from the schema.

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% and all eight parameters (page, per_page, sort, order_by, owned, membership, search, visibility) are documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 is appropriate.

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?

It gives a specific verb and resource ("List GitLab projects") and adds a scope qualifier ("accessible by the API token"), which clearly separates it from the singular get_project_tool. It does not, however, explicitly distinguish itself from list_group_projects_tool or search_project_tool, so sibling differentiation is only partial.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus list_group_projects_tool, search_project_tool, or get_project_tool, nor any mention of prerequisites or how to page through results. The phrase "accessible by the API token" implies a scope but does not state when this tool is the right choice.

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