Skip to main content
Glama
Sign In
GitFlic MCP Server

GitFlic MCP Server

by zhimbura
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

gitflic_mr_discuss_list

Read-only

Lists all discussions and their replies on a GitFlic merge request, with optional pagination and field selection for reviewing feedback.

Instructions

List discussions (with replies) on a merge request.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>",
      "id": "<id>"
    },
    "name": "gitflic_mr_discuss_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
allNoFetch all pages. Defaults to true when page is omitted.
rawNoReturn the full, un-slimmed GitFlic response for THIS call (no token compression). Use when the default slim view dropped a field you need.
pageNoZero-based page index; selects one page unless all is true.
sizeNoRequested page size; server limits are respected.
fieldsNoReturn only these top-level fields (plus id keys), narrowing the response further.
projectYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.6/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — replies are included inline — but says nothing about pagination defaults, result ordering, or what identifying metadata a discussion carries.

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?

A single ten-word sentence, front-loaded with the verb and resource, with the one qualifier that changes expectations ('with replies') in parentheses rather than buried. Nothing is wasted.

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?

With seven parameters, no output schema, and a paginated/compressed response model, the description is minimal but the schema documents the pagination and slim/raw controls. Missing is any hint about what a discussion record contains (resolution state, author, position) that would help an agent interpret or follow up with the resolve/reply siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 71% and the parameters that carry behavioral subtlety (all defaulting to true when page is omitted, raw bypassing the slim view, fields narrowing output) are all documented inline in the schema. The description adds nothing parameter-specific, but with that coverage the schema does the work; '(with replies)' loosely frames the payload shape.

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?

States a specific verb and resource: 'List discussions' on a merge request, and the parenthetical '(with replies)' signals the nested reply content, which separates it from the sibling gitflic_mr_discuss_reply. It stops short of naming any sibling explicitly, so differentiation relies on the reader already knowing the rest of the catalog.

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

Usage Guidelines3/5

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

The use case (reading discussions on an MR) is implied by the verb and scope but never stated as a when-to-use rule. There is no exclusion guidance — nothing says whether to prefer this over gitflic_mr_list or a comments-listing sibling, nor any prerequisite such as needing the MR id.

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