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

atlassian-browser-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Batch Create Versions

jira_batch_create_versions

Create multiple Jira project versions in one batch from a project key and JSON array of version details, avoiding repeated single-version creation.

Instructions

Batch create multiple versions in a Jira project.

Input Schema

NameRequiredDescriptionDefault
versionsYesJSON array of version objects. Each object should contain: - name (required): Name of the version - startDate (optional): Start date (YYYY-MM-DD) - releaseDate (optional): Release date (YYYY-MM-DD) - description (optional): Description of the version Example: [ {"name": "v1.0", "startDate": "2025-01-01", "releaseDate": "2025-02-01", "description": "First release"}, {"name": "v2.0"} ]
project_keyYesJira project key (e.g., 'PROJ', 'ACV2')

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.1
    • addedInput schema / additionalProperties
      Added value: +false
    • removedOutput schema / description
      Removed value: -"Generic wrapper for non-object return types."
  2. Addedv1.0.1

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare mutation, open-world, non-idempotent, and non-destructive behavior, so the description does not need to repeat those basics. However, it adds no batch-specific behavioral context such as partial-failure handling, atomicity, duplicate-name handling, or required Jira permissions.

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?

The description is a single front-loaded sentence with no filler or repetition. It is maximally concise for what it attempts to communicate.

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?

Although the schema and output schema are rich and annotations cover the basic safety profile, this is a batch mutation tool where atomicity and partial-success behavior matter. The description does not address those operational risks or how the batch result should be interpreted.

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%: project_key and the JSON-array versions parameter are fully documented in the schema, including each version object field and an example. The description adds no parameter meaning beyond the schema, 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?

The description names a specific verb and resource: batch creating multiple versions in a Jira project. It implicitly distinguishes itself from the single-version sibling jira_create_version by emphasizing 'batch' and 'multiple', but it does not explicitly name or route away from that sibling.

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?

The word 'batch' implies this is for creating more than one version at once, but there is no explicit guidance on when to use this instead of jira_create_version, no prerequisites, and no exclusions such as duplicate-version behavior.

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