Skip to main content
Glama
Sign In
atlassian-browser-mcp

atlassian-browser-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Board Issues

jira_get_board_issues
Read-onlyIdempotent

Retrieves Jira issues from a specific board using a JQL filter, with pagination and selectable fields. Use it to list board issues matching custom queries.

Instructions

Get all issues linked to a specific board filtered by JQL.

Input Schema

NameRequiredDescriptionDefault
jqlYesJQL query string (Jira Query Language). Examples: - Find Epics: "issuetype = Epic AND project = PROJ" - Find issues in Epic: "parent = PROJ-123" - Find by status: "status = 'In Progress' AND project = PROJ" - Find by assignee: "assignee = currentUser()" - Find recently updated: "updated >= -7d AND project = PROJ" - Find by label: "labels = frontend AND project = PROJ" - Find by priority: "priority = High AND project = PROJ"
limitNoMaximum number of results (1-50)
expandNoOptional fields to expand in the response (e.g., 'changelog').version
fieldsNoComma-separated fields to return in the results. Use '*all' for all fields, or specify individual fields like 'summary,status,assignee,priority'assignee,created,description,issuetype,labels,priority,reporter,status,summary,updated,versions
board_idYesThe id of the board (e.g., '1001')
start_atNoStarting index for pagination (0-based)

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.1
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / fields / default
      Previous value: -"labels,versions,priority,description,reporter,status,summary,created,issuetype,updated,assignee"New value: +"assignee,created,description,issuetype,labels,priority,reporter,status,summary,updated,versions"
    • removedOutput schema / description
      Removed value: -"Generic wrapper for non-object return types."
  2. Changed1 schema field changedv1.2.1
    • changedInput schema / properties / fields / default
      Previous value: -"reporter,status,priority,created,issuetype,summary,updated,labels,description,assignee"New value: +"labels,versions,priority,description,reporter,status,summary,created,issuetype,updated,assignee"
  3. Changed1 schema field changed
    • changedInput schema / properties / fields / default
      Previous value: -"summary,issuetype,description,status,updated,created,reporter,labels,assignee,priority"New value: +"reporter,status,priority,created,issuetype,summary,updated,labels,description,assignee"
  4. Addedv1.0.1

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is settled elsewhere. The description adds only that results are board-linked and JQL-filtered; it says nothing about pagination behavior (start_at/limit cap of 50) or result shape, which matters for a read tool returning potentially large sets.

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?

A single front-loaded sentence with no filler; the verb, scope, and filter mechanism all land immediately. It is efficient, though its brevity leaves the routing gaps noted above unaddressed.

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?

An output schema exists and all six parameters are documented, so the description need not explain return values. However, for a tool sitting beside jira_search, jira_get_sprint_issues, and jira_get_project_issues, the one-liner does not supply the board-vs-project-vs-search disambiguation an agent needs to pick correctly.

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

Parameters3/5

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

Schema description coverage is 100%, including a rich JQL example set, so the schema carries the parameter burden and baseline 3 applies. The description adds no syntax, format, or interaction detail (e.g., that fields/expand shape the response, or that limit caps at 50) beyond what the schema already documents.

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 ('Get all issues') with a clear scope qualifier ('linked to a specific board filtered by JQL'). An agent can tell this apart from a general search, though the description never names the closest sibling (jira_search) to sharpen the distinction.

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 board-scoped framing implies when this tool applies (board context, JQL filtering), but there is no explicit 'use this instead of jira_search / jira_get_project_issues when...' guidance and no stated prerequisites such as needing a board_id before you have one.

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