Loading ToolBench
MCP server (stdio) — proxy fino sobre a REST API v4 de um GitLab CE self-hosted, focado em navegar MRs e deixar review inline.
gitlab-mcp has 13 well-named tools with consistent verb_noun patterns (list_, get_, comment_, reply_). All tools have descriptions in Portuguese (10 - 200 chars, within baseline 34 - 392). Input schemas are present and typed for all tools. However, parameter descriptions lack actionable constraints (no enums for state values, no min/max for pagination, no format specs). Output schemas are undocumented, LLMs cannot predict response structure for chaining. Error handling is absent from visible code. Tool descriptions are functional but generic; they do not explain WHEN to use each tool vs. similar ones (e.g., comment_on_mr vs. comment_on_mr_line). No tool annotations (readOnlyHint, destructiveHint) despite clear read/write distinction. Pagination is present but limits (20 - 100) are buried in descriptions, not enforced in schema.
Comenta no merge request (no corpo, não em linha).
Comenta em uma linha específica do diff do merge request.
Retorna o trace (log) de um job da pipeline.
Retorna detalhes completos de um merge request.
Diff do merge request em texto, com o número de linha de cada lado impresso explicitamente (old=/new=). Use antes de comentar em linha: os números old= e new= que aparecem aqui são exatamente os que comment_on_mr_line espera. Prefixos: "add" = linha só no lado novo, "del" = linha só no antigo, "ctx" = linha inalterada (tem os dois números). Se a saída vier truncada por contagem de linhas, chame de novo com path="<arquivo>" para ver aquele arquivo isolado. Se o aviso disser que o limite de TAMANHO da resposta foi atingido, o mesmo teto vale na chamada isolada — veja o arquivo no browser se faltar contexto. Não use para ler o arquivo completo do repositório — só mostra o que mudou no MR.
Retorna a pipeline mais recente de um merge request com seus jobs.
Output schemas undocumented. LLMs cannot predict response structure (fields, types, pagination format) for downstream tool chaining. E.g., list_mrs returns what fields? Does it include project_id for get_mr? Does it return next_cursor or page/total?
Parameter constraints missing. 'state' in list_mrs accepts 'opened|closed|locked|merged' but is not declared as enum in schema, LLM may hallucinate invalid values. Pagination limits (20 - 100) are in description text, not enforced as minItems/maxItems in schema.
No tool annotations. Tools are marked Risk: READ_ONLY or WRITE in metadata, but schema lacks readOnlyHint/destructiveHint/idempotentHint. LLMs cannot infer safety properties from the tool definition alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Lista discussões (comentários e threads) de um merge request.
Lista merge requests do projeto.
Lista merge requests que aguardam review do usuário autenticado.
Lista projetos do usuário autenticado.
Lista pipelines de uma branch ou commit.
Responde a uma discussão (thread) de um merge request.
Retorna o usuário autenticado no GitLab.
Error handling absent from visible code. No recovery guidance. If get_mr returns 404 (MR not found), does the tool suggest list_mrs? If comment_on_mr_line fails with 'invalid line number', does it guide the user to call get_mr_diff first?
Descriptions lack WHEN-to-use guidance. 'comment_on_mr' and 'comment_on_mr_line' both add comments but differ in scope. Description does not explain: use comment_on_mr for general feedback, comment_on_mr_line for code-specific review. LLMs may pick wrong tool.