Skip to main content
Glama

jira_bulk_create

Bulk-create JIRA issues and link dependencies in one call. Use aliases to wire links between newly created issues, and get a YAML report to retry only failed items.

Instructions

Bulk-create JIRA issues and (optionally) wire dependency links between them in one call — built for epic decomposition. issues are created in order and each may carry a local alias. links are created afterward; each inward/outward is resolved alias-first (to the freshly-minted key) else treated as an existing issue key, so you can link issues this same call just created. Default is continue-on-error: every record is attempted and a YAML report lists per-issue {alias, ok, key, self_url | error}, per-link {ok | error}, and a summary. Set fail_fast to stop at the first failure. NOTE: JIRA has no transaction — nothing is rolled back; the report always shows exactly what succeeded so you can retry only the remainder. To link existing issues only, pass an empty issues array and reference real keys in links.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linksNoDependency links to create after the issues. Each endpoint is resolved alias-first (to the freshly-minted key), else treated as an existing issue key.
issuesYesIssues to create, in order. May be empty to only create `links` between existing issues.
fail_fastNoWhen true, stop at the first failed create or link instead of continuing. The partial report is still returned. Defaults to false (continue-on-error).
Behavior5/5

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

With no annotations, the description carries the full burden and does so excellently: it discloses the creation order, alias-first link resolution, continue-on-error default, YAML report contents, fail_fast behavior, and the critical 'no transaction / no rollback' caveat. This more than satisfies transparency.

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 dense paragraph that front-loads the purpose, then efficiently explains alias resolution, error handling, report format, and transactionality. Every sentence contributes necessary information without 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?

Despite having no output schema, the description fully specifies the YAML report structure (per-issue fields, per-link status, summary) and covers edge cases (empty issues array, failure continuation, partial failures). The tool's complexity is matched by a complete and self-contained description.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds cross-parameter semantics: how aliases bridge issues and links, the ordering of operations, and the interaction of fail_fast with the report. This adds value beyond the isolated parameter descriptions in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool bulk-creates JIRA issues and optionally wires dependency links between them, explicitly positioning it for epic decomposition. This distinguishes it from single-issue creation (jira_create) and single-link creation (jira_link_create) via the bulk + link combination.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: built for epic decomposition, and it even covers a specific scenario (linking existing issues only via an empty issues array). It does not explicitly name alternative tools or state when not to use it, but the context is unambiguous enough for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rust-works/omni-dev'

If you have feedback or need assistance with the MCP directory API, please join our Discord server