Skip to main content
Glama

List issues

list_issues
Read-only

List issues in a repository with filters for state, labels, milestones, author, assignee, mentions, and text search. Pull requests are excluded; use the dedicated pull request tool instead.

Instructions

List issues in a repository (owner/repo), open by default; optional state (open/closed/all) and page/limit. Filters: labels and milestones (names; an issue with any of them matches), author, assignee, mentioned (logins), search (text), since/before (RFC 3339, by last update). A label or milestone name the forge does not know is refused rather than ignored, since the forge would then list every issue. sort orders the list (oldest, recentupdate, mostcomment, nearduedate, …) on Forgejo only: Gitea's issue listing has no sort, so there it is refused. Issues only — pull requests, which the forges also serve as issues, are left out; use list_pull_requests for those. Each issue is slimmed to number, title, state, author, labels, assignees, milestone, comment count and dates, without its body; get_issue has the body.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number.
repoYesRepository name, e.g. `forgejo-mcp-rs`.
sortNoOrder: `latest` (the default, newest first), `oldest`, `recentupdate`, `leastupdate`, `mostcomment`, `leastcomment`, `nearduedate`, `farduedate`, or `relevance` (with `search`). Forgejo only: Gitea's issue listing has no sort, so anything but `latest` is refused there.
limitNoResults per page.
ownerYesRepository owner — user or organization, e.g. `brechanbech`.
sinceNoOnly issues updated at or after this time (RFC 3339, e.g. `2026-10-01T00:00:00Z`).
stateNoFilter by state: `open` (default), `closed`, or `all`.
authorNoOnly issues opened by this login.
beforeNoOnly issues updated before this time (RFC 3339).
labelsNoOnly issues carrying any of these label names.
searchNoOnly issues matching this text.
assigneeNoOnly issues assigned to this login.
mentionedNoOnly issues mentioning this login.
milestonesNoOnly issues in any of these milestones, by name (or id).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.26.0
    • addedInput schema / properties / assignee
      Added value: +{
      +  "default": null,
      +  "description": "Only issues assigned to this login.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / author
      Added value: +{
      +  "default": null,
      +  "description": "Only issues opened by this login.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / before
      Added value: +{
      +  "default": null,
      +  "description": "Only issues updated before this time (RFC 3339).",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / labels
      Added value: +{
      +  "default": null,
      +  "description": "Only issues carrying any of these label names.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": [
      +    "array",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / mentioned
      Added value: +{
      +  "default": null,
      +  "description": "Only issues mentioning this login.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / milestones
      Added value: +{
      +  "default": null,
      +  "description": "Only issues in any of these milestones, by name (or id).",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": [
      +    "array",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / search
      Added value: +{
      +  "default": null,
      +  "description": "Only issues matching this text.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / since
      Added value: +{
      +  "default": null,
      +  "description": "Only issues updated at or after this time (RFC 3339, e.g. `2026-10-01T00:00:00Z`).",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / sort
      Added value: +{
      +  "default": null,
      +  "description": "Order: `latest` (the default, newest first), `oldest`, `recentupdate`, `leastupdate`,\n`mostcomment`, `leastcomment`, `nearduedate`, `farduedate`, or `relevance` (with\n`search`). Forgejo only: Gitea's issue listing has no sort, so anything but `latest` is\nrefused there.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  2. First observedv0.22.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnly/openWorld; the description goes far beyond by disclosing forge-specific behavior (invalid label/milestone names are refused rather than silently ignored, sort is Forgejo-only and refused on Gitea) and the slimmed return shape. These are non-obvious failure modes an agent could otherwise trip over.

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?

Front-loaded with scope then filters then caveats, and nearly every clause carries actionable information. It is dense and long-ish for a single paragraph, but no sentence is pure filler.

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

Completeness5/5

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

With 14 parameters and no output schema, the description compensates by summarizing the returned fields (number, title, state, author, labels, assignees, milestone, comment count, dates; no body). Nothing critical for correct invocation is missing.

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 100%, so baseline is 3, and the description adds meaningful semantics: labels/milestones match on ANY name, since/before are by last update, and sort's availability depends on the forge. It does not enumerate every sort value or page/limit interplay, but the schema covers those.

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

Purpose5/5

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

States a specific verb and resource ('List issues in a repository (owner/repo)') plus the default scope (open only). It explicitly carves out the sibling boundary by excluding pull requests and naming list_pull_requests as the alternative.

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

Usage Guidelines5/5

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

Gives explicit routing: use list_pull_requests for PRs, get_issue for the body, and states the default state filter. It also flags when the sort parameter is unavailable (Gitea) and when label/milestone names will be refused, which is exactly the guidance an agent needs before calling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.