Skip to main content
Glama

Search issues

search_issues
Read-onlyIdempotent

Search issues.

Returns summaries (with each issue's version and sprint). Filters combine with AND; array filters are OR within the filter. assignee=me for your issues. Paginated with cursor/next_cursor. sprint: a sprint id (S-3) for one sprint, backlog for issues in no sprint, or active for issues in ANY active sprint — a project can run several sprints at once, so when the user means one of them, call list_sprints (state=active) and filter by that sprint's id; read each result's sprint to tell them apart. priority: one or more of highest, high, medium, low, lowest (issues without one count as medium); order=priority sorts highest first, then by rank; order=votes (D143) sorts by votes, most first, then by rank. Each summary carries votes (count) and my_vote. release (D113): a release id (R-3) for the issues that ship in it — epic children included — or none; each result's in_release is the release it ships in. severity: critical, high, medium, low (bugs). hide_released=true (D188) leaves out done issues whose release is already released (shipped to production) and says how many in omitted_released — use it for "what is not in production yet / งานที่ยังไม่ขึ้น production". Templates (spec D129/D130): flag filters by the flags board-core computes from the custom fields and today (Asia/Bangkok) — never stored, so never guess them from status. Sales & Billing: overdue = invoiced installment, unpaid, past due_on; due_soon = invoiced, unpaid, due within due_soon_days; bill_due = installment to invoice now (bill_on reached, not invoiced); awaiting_signature = deal in Sent for ≥ awaiting_sign_days; all_paid = deal fully collected but not Closed yet. Service desk: sla_soon (SLA due within a day), sla_over (past SLA; neither in Waiting / done). Budget planning: over_budget (actual > planned), spent_warn (≥ spent_warn_pct % spent). Several flags = OR. Installments are type: subtask with parent = the deal: "which deals are unpaid / ดีลไหนค้างชำระ" → flag: ["overdue"] (each result's parent is the deal; name the customer from the deal's fields.customer); every installment not yet paid → type: ["subtask"] + fields: '[{"id":"paid_at","op":"empty"}]'. fields is a JSON STRING of [{id, op, value}] — ops eq, ne, lt, lte, gt, gte, between (value = array of two), in (array), empty, not_empty (no value); today for date fields, me for person fields — e.g. '[{"id":"due_on","op":"between","value":["2026-10-06","2026-10-12"]},{"id":"paid_at","op":"empty"}]'; all conditions must hold; field ids come from get_project fields (unknown → 400 unknown_field). sort_field (+ sort_dir asc | desc) sorts by a custom field, issues without a value last. Each result carries fields, flags, computed (formula and rollup values) and, for a deal, children (count, done, amount_total, paid_total, paid_count). Roadmap & Goals (spec D131): on_track / at_risk / off_track are computed from a goal's start, end and rollup progress — off_track = past end and progress < 100, at_risk = elapsed % of start→end minus progress % > 25 (before end), on_track = the rest; none for done goals or goals without dates. "เป้าหมาย Q4 ไหนล่าช้า / which Q4 goals are late?" → flag: ["off_track"] + fields: '[{"id":"quarter","op":"eq","value":"Q4"}]' (read computed.progress and fields.owner to answer). linked_to = an issue key of ANY project of the company or a release KEY/R-n: the issues of this project that link to it ("what depends on KJ-120 / what delivers release R-3?"). Results do not resolve their links — get_issue does (linked[]).

Input Schema

NameRequiredDescriptionDefault
flagNoOne or more computed template flags (spec D130 (3), D129 (10)): e.g. `overdue` = invoiced, unpaid installments past due_on; `bill_due` = installments to invoice today; `awaiting_signature` = deals waiting for the customer; `sla_over` = requests past their SLA; `over_budget`. Flags are computed from the issue's custom fields and today (Asia/Bangkok), never stored.
textNoText search over the title, the body and the issue key — whole or in part (e.g. BMTK-3, bmtk); an exact key comes first.
typeNo
labelNo
limitNo
orderNo`rank` = board/backlog order (manual order, issues without a rank last); `updated` = newest change first; `priority` = highest first, then rank (D89); `votes` = most votes first, then rank (D143; projects with votes off: every count is 0, so it equals `rank`).rank
cursorNoOpaque cursor from the previous page's `next_cursor`.
fieldsNoCustom-field conditions (spec D129 (6)) as a JSON array of `{id, op, value}` (`fieldFilter`), e.g. `[{"id":"due_on","op":"lt","value":"today"},{"id":"paid_at","op":"empty"}]`. Unknown field id → 400 `unknown_field`; a value that does not fit the field type → 400 `invalid_field_value`. All conditions must hold.
parentNoIssue key `{PROJECT}-{n}`, e.g. `KJ-101`.
sprintNoSprint id, or `backlog` for issues in no sprint, or `active`.
statusNo
releaseNoRelease id (D113) — the issues in it, epic children included (their own `release` null) — or `none` for issues in no release. Projects with releases off → 403 feature_disabled.
assigneeNoUser id, or `none` for unassigned, or `me`.
priorityNoOne or more priorities (D89); issues without the key count as medium.
severityNoOne or more bug severities (D113).
sort_dirNoasc
linked_toNoIssues of this project that link to the given target (spec D131 (1)): an issue key of any project of the company or a release `KEY/R-n`.
done_sinceNoLeave out finished work older than this (S100, PO 2026-09-30): issues in a done-category status whose `done_at` (or `updated_at` when the file has no `done_at`) is before this timestamp are not returned, and `omitted_done` says how many were left out. The board sends the start of the current week (Monday 00:00 Asia/Bangkok). Other statuses are unaffected. Omit it to get every issue.
sort_fieldNoSort by a custom field (spec D129 (4), (6)) instead of `order`: date / number / money fields sort by value, text by text; issues without the value come last.
project_keyYesProject key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.
hide_releasedNoLeave out shipped finished work (S173, spec D188 (4)): issues in a done-category status whose effective release (their own `release`, else their nearest ancestor's — D113) is `released` are not returned, and `omitted_released` says how many were left out. Works together with `done_since`. Other statuses and planned releases are unaffected. The board sends it on Kanban and Delivery pipeline boards with releases on; projects with releases off ignore it. Omit it (or `false`) to get every issue.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / hide_released
      Added value: +{
      +  "default": false,
      +  "description": "Leave out shipped finished work (S173, spec D188 (4)): issues in a done-category status whose effective release (their own `release`, else their nearest ancestor's — D113) is `released` are not returned, and `omitted_released` says how many were left out. Works together with `done_since`. Other statuses and planned releases are unaffected. The board sends it on Kanban and Delivery pipeline boards with releases on; projects with releases off ignore it. Omit it (or `false`) to get every issue.",
      +  "type": "boolean"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / order / description
      Previous value: -"`rank` = board/backlog order (manual order, issues without a rank last); `updated` = newest change first; `priority` = highest first, then rank (D89)."New value: +"`rank` = board/backlog order (manual order, issues without a rank last); `updated` = newest change first; `priority` = highest first, then rank (D89); `votes` = most votes first, then rank (D143; projects with votes off: every count is 0, so it equals `rank`)."
    • changedInput schema / properties / order / enum
      Previous value: -[
      -  "rank",
      -  "updated",
      -  "priority"
      -]New value: +[
      +  "rank",
      +  "updated",
      +  "priority",
      +  "votes"
      +]
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already establish a safe, idempotent read, but the description goes well beyond: flags are computed at read time from custom fields and today (Asia/Bangkok), never stored, so they must not be inferred from `status`; results carry `omitted_done`/`omitted_released` counts; unknown field ids return 400 `unknown_field` and releases-off projects return 403 `feature_disabled`. That is substantial non-obvious behavior an agent could not get from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is valuable but the structure is a single dense wall: return-value details appear before the filter semantics, and large blocks (flag definitions, `hide_released`, `order`) restate the input schema's descriptions nearly verbatim. Every sentence is arguably substantive, but the density and duplication make it hard to scan.

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

Completeness4/5

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

For 21 parameters with no output schema, the description is unusually complete: it documents pagination via `cursor`/`next_cursor`, the per-result fields, computed-vs-stored distinction, error behavior, and cross-tool follow-ups. Minor gaps remain, such as the meaning of the `limit` default/max and whether a total count is returned.

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

Parameters5/5

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

Schema coverage is 76%, but the description adds real meaning on top: `fields` is a JSON *string* of `{id, op, value}` with the full op vocabulary and `today`/`me` sentinels plus a worked example, `flag` values are explained in domain terms (overdue = invoiced unpaid past `due_on`), and `priority`/`order=priority` ordering and the medium default for missing values are spelled out. This is far above what the schema alone conveys.

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?

The definition opens with a specific verb+resource and describes the result shape (summaries carrying `version`, `sprint`, `flags`, `computed`). It actively differentiates from `get_issue` ("Results do not resolve their links — get_issue does") and routes sprint disambiguation to `list_sprints`, though it never distinguishes itself from `list_my_issues`, which overlaps on the assignee=me case.

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

Usage Guidelines4/5

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

It gives concrete routing rules for tricky cases: use `list_sprints(state=active)` before filtering by a single active sprint, use `linked_to` when asked what depends on an issue, use `get_issue` for resolved links, and use `hide_released` for "not in production yet" questions. It stops short of explicit exclusions (e.g., when to prefer `list_my_issues` or `get_project_insights` instead).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources