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

atlassian-browser-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Issues Development Info

jira_get_issues_development_info
Read-onlyIdempotent

Batch retrieve development panel information—pull requests, commits, and branches—for multiple Jira issues to review linked code activity in one request.

Instructions

Get development information for multiple Jira issues.

Batch retrieves development panel information (PRs, commits, branches) for multiple issues at once.

Input Schema

NameRequiredDescriptionDefault
data_typeNo(Optional) Filter by data type. Examples: 'pullrequest', 'branch', 'repository'
issue_keysYesComma-separated list of Jira issue keys (e.g., 'PROJ-123,PROJ-456')
application_typeNo(Optional) Filter by application type (case-sensitive). Examples: 'stash' (Bitbucket Server), 'bitbucket', 'GitHub', 'githube' (GitHub Enterprise Server), 'GitLab'. If omitted, types are discovered automatically.

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 / application_type / description
      Previous value: -"(Optional) Filter by application type (case-sensitive). Examples: 'stash' (Bitbucket Server), 'bitbucket', 'GitHub', 'GitLab'"New value: +"(Optional) Filter by application type (case-sensitive). Examples: 'stash' (Bitbucket Server), 'bitbucket', 'GitHub', 'githube' (GitHub Enterprise Server), 'GitLab'. If omitted, types are discovered automatically."
    • removedOutput schema / description
      Removed value: -"Generic wrapper for non-object return types."
  2. Changed1 schema field changedv1.2.1
    • changedInput schema / properties / application_type / description
      Previous value: -"(Optional) Filter by application type. Examples: 'stash' (Bitbucket Server), 'bitbucket', 'github', 'gitlab'"New value: +"(Optional) Filter by application type (case-sensitive). Examples: 'stash' (Bitbucket Server), 'bitbucket', 'GitHub', 'GitLab'"
  3. Addedv1.0.1

TDQS

A3.6/5.0
Behavior3/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 fully covered by structured data. The description adds only that data comes from the development panel (PRs, commits, branches); it says nothing about permission requirements, rate limits, or behavior when an issue has no development data, which the annotations do not cover.

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?

Two short sentences, front-loaded with the action, and the second adds the useful enumeration of what 'development information' contains. There is mild redundancy between 'for multiple Jira issues' and 'for multiple issues at once', but no real waste.

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?

An output schema exists so return values need not be explained, parameter coverage is complete in the schema, and annotations carry the safety profile. The description supplies exactly the remaining piece – the nature of the retrieved development data and its batch scope – so nothing needed to call it correctly is missing.

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%, so the schema already explains issue_keys, data_type and application_type in detail. The description contributes nothing beyond 'multiple issues at once', so the baseline of 3 applies.

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 development information for multiple Jira issues') and clarifies the payload as development panel data (PRs, commits, branches). The 'multiple issues' / 'Batch' framing implicitly distinguishes it from the singular sibling jira_get_issue_development_info, but the sibling is never named.

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?

Usage is implied rather than stated: the word 'Batch' signals this is for multi-issue retrieval, which suggests the singular sibling is the alternative for one issue. There is no explicit when-to-use/when-not guidance, no mention of prerequisites, and no named alternative.

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