Skip to main content
Glama

search_issues

Search the issues visible to this token, with a JQL query — the same JQL the Jira REST surface takes, read by the same parser. A query naming a field this tracker does not have is REFUSED and named, never run: it would match everything and read as an answer. Without jql, the shorthand arguments filter instead. Most recently created first unless the query says ORDER BY. Archived issues are left out unless the query names archived, and archivedLeftOut says how many matches that hid — an empty list with it is not "there are none".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jqlNoA JQL query, e.g. `assignee = currentUser() AND statusCategory != Done ORDER BY updated DESC`. FIELDS: project, status, statuscategory, issuetype, type, priority, resolution, assignee, reporter, creator, key, issuekey, id, summary, description, sprint, parent, epic, labels, archived, agent, text, created, updated, duedate. OPERATORS: = != ~ !~ > >= < <=, IN (...), NOT IN (...), IS EMPTY, IS NOT EMPTY, combined with AND / OR, with parentheses around a sub-expression — `project = PM AND (status = Blocked OR priority = Highest)` — plus an optional trailing ORDER BY <field> [DESC]. `~` means contains (substring) and is the one to use for free text — `text` searches summary, description and comments. `>` `>=` `<` `<=` are for created/updated/duedate only, with absolute YYYY-MM-DD values: there are NO relative-date functions, so compute the date yourself. The only function is currentUser(), for assignee/reporter/creator. `archived` is this tracker's own field: archived issues are left out unless the query mentions it. `epic` is this tracker's own too, and it is the wide one: `epic = PM-12` matches that epic AND the work under it — its children and their sub-tasks — which is how one asks for an epic's whole board in a single clause. `parent` is the narrow one: direct children only, and never the epic itself. `agent` is this tracker's own as well: `agent = product` is an issue an agent of that role has right now — working on it or waiting on its question — and `agent IS NOT EMPTY` is any agent; the assignee of such an issue is still the person it works for. Quote values containing spaces. Seeded values — status: Backlog, "To Do", "In Progress", "In Review", Blocked, Done; statusCategory: "To Do", "In Progress", Done; priority: Highest, High, Medium, Low, Lowest; type: Epic, Story, Task, Bug, "Sub-task". A project's own columns (PM-170) can be searched too, by name — Segment = AI — or as customfield_20003 / cf[20003]; list_project_fields names them.
textNoShorthand for `key ~ … OR summary ~ …`. Narrows the query further when `jql` is given too.
limitNoMax issues to return (default 25, max 100).
statusNoShorthand for `status = …` (e.g. 'In Progress', 'Done'). Narrows the query further when `jql` is given too.
projectKeyNoShorthand for `project = …` (must be visible to the token). Narrows the query further when `jql` is given too.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden. It discloses that unknown fields are refused and named, that archived issues are excluded unless the query mentions archived, that archivedLeftOut indicates hidden matches, and that the default ordering is most-recent-first.

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?

Every sentence earns its place: purpose is front-loaded, then shorthand behavior, ordering, and the archived caveat. Dense but not padded.

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?

For a complex JQL search tool with no output schema, the description plus the exhaustive jql parameter schema covers evaluation, error behavior, filtering semantics, and result-count caveats. An agent has enough to invoke it correctly.

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 per-parameter details are already thorough. The description adds valuable cross-cutting semantics: default ordering, archived-exclusion behavior, the refusal behavior for unknown fields, and the shorthand fallback.

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?

The description opens with a specific verb and resource: 'Search the issues visible to this token, with a JQL query.' This clearly differentiates it from the sibling search_code and search_wiki tools and from get_issue.

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 clear context for when to use JQL versus shorthand filters, and explains how shorthand arguments combine with jql. It does not explicitly compare against sibling tools, but the usage context is otherwise unambiguous.

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