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

atlassian-browser-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Sprint Issues

jira_get_sprint_issues
Read-onlyIdempotent

Retrieve Jira issues from a specified sprint with pagination, field selection, and result limits for sprint review, backlog grooming, or reporting.

Instructions

Get jira issues from sprint.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of results (1-50)
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
start_atNoStarting index for pagination (0-based)
sprint_idYesThe id of sprint (e.g., '10001')

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

C2.5/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of pagination behavior, ordering, default result cap, or what happens with an invalid sprint id — all of which matter for a listing tool with openWorld semantics.

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 single six-word sentence is front-loaded and has zero waste, but it is under-specified rather than genuinely concise — the brevity removes information an agent needs rather than trimming redundancy.

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?

An output schema exists, so return values need not be described. But for a paginated listing tool sitting among several similar issue-listing siblings, the description omits pagination expectations, the relationship between sprint_id and board context, and differentiation from alternatives — leaving it materially incomplete.

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%, with limit, fields, start_at, and sprint_id all documented inline including defaults, ranges, and an example id. The description contributes no additional parameter meaning, so the baseline 3 applies.

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?

The description states a verb ('Get') and a resource ('jira issues') scoped to a sprint, which is marginally more than the name alone. However, it does not distinguish this from closely related siblings such as jira_get_board_issues, jira_get_project_issues, or jira_search, so an agent cannot route confidently between them from the description alone.

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?

There is no guidance on when to use this tool versus jira_search, jira_get_board_issues, or jira_get_project_issues, nor any statement of prerequisites (e.g., that a sprint id must be obtained via jira_get_sprints_from_board). Usage is left entirely to inference.

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