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

atlassian-browser-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Issue Development Info

jira_get_issue_development_info
Read-onlyIdempotent

Retrieve linked pull requests, branches, and commits for a Jira issue to track development activity and source control connections.

Instructions

Get development information (PRs, commits, branches) linked to a Jira issue.

This retrieves the development panel information that shows linked pull requests, branches, and commits from connected source control systems like Bitbucket, GitHub, or GitLab.

Input Schema

NameRequiredDescriptionDefault
data_typeNo(Optional) Filter by data type. Examples: 'pullrequest', 'branch', 'repository'
issue_keyYesJira issue key (e.g., 'PROJ-123')
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.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real context beyond them: results come from the development panel and depend on connected source control systems like Bitbucket, GitHub, or GitLab. That explains the expected empty-result case, though it stops short of noting permission or integration-configuration prerequisites.

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, capability stated first, zero filler. The second sentence partially re-lists the same artifacts before adding the source-system detail, a minor redundancy.

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?

With an output schema present, fully documented parameters, and read-only/idempotent annotations, the description supplies everything an agent needs to call it correctly. Its only gap—disambiguation from the plural sibling—is a routing concern rather than a completeness one.

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%—issue_key, data_type and application_type are all documented in the schema with examples. The description adds no filtering or format guidance beyond that, so the baseline 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?

Names a specific verb and resource—'Get development information (PRs, commits, branches) linked to a Jira issue'—which is far more precise than the tautological title. It does not, however, differentiate itself from the close sibling jira_get_issues_development_info (plural), leaving the agent to infer the single-vs-multiple-issue split from the name alone.

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: fetch linked PRs/branches/commits for one issue. There is no explicit when-to-use, when-not, or pointer to jira_get_issues_development_info for batch lookups, and no note that an empty result is normal when no SCM integration exists.

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