Skip to main content
Glama

gitflic_issue_list

Read-only

Lists issues in a GitFlic project, with filters for status, assignee, label, search text, sorting, and pagination to find and review relevant work items.

Instructions

List issues. Filter by --status if needed.

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>"
    },
    "name": "gitflic_issue_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoFree-text filter over title + description.
rawNoReturn the full, un-slimmed GitFlic response for THIS call (no token compression). Use when the default slim view dropped a field you need.
pageNo
sizeNo
sortNoSort by a field; prefix '-' for descending (e.g. '-createdAt').
labelNoKeep only issues with a label whose title contains this (case-insensitive).
limitNoReturn at most N issues after filtering/sorting.
fieldsNoReturn only these top-level fields (plus id keys), narrowing the response further.
statusNo
projectYes
assigneeNoKeep only issues assigned to this username.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds nothing beyond that – it doesn't mention pagination behavior, default result limits, or the token-slimming/`raw` behavior called out in the schema, which are real behavioral traits an agent should know.

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 very short sentences, front-loaded with the core action, with no filler. The only flaw is the stray "--" flag notation, which adds confusion rather than value.

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

Completeness2/5

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

For an 11-parameter listing tool with no output schema, the description is far too thin: it omits pagination (page/size), sorting, field projection, free-text search, assignee/label filters, and the token-compression caveat. An agent would have to read the schema to use the tool well, and even then several parameters are undocumented.

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

Parameters2/5

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

Schema coverage is 64% across 11 parameters, so the schema documents many of them (q, raw, sort, label, limit, fields, assignee) but leaves status, page, size, and project undocumented. The description only names status – and does so in a mismatched CLI flag style – so it fails to compensate for the remaining gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"List issues" states a clear verb and resource, so an agent knows the operation. However, it offers no differentiation from siblings such as gitflic_issue_view or the other issue sub-resource listers, and does not indicate the scope (project-wide vs. filtered).

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?

The only guidance is "Filter by --status if needed," which is a weak conditional and uses CLI-flag notation that doesn't match the JSON parameter name "status." There is no mention of when to prefer gitflic_issue_view or other siblings, no prerequisites, and no note on combining filters.

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