jira-delivery-mcp

Write an agent workflow pack into the repo

delivery_generate_agent_pack

DestructiveIdempotent

Write reusable Jira delivery prompts and commands for coding agents into repository directories, supporting Claude, Codex, or generic formats.

Instructions

Write reusable Jira delivery prompts/commands for a coding agent into the repository (claude: .claude/commands and .claude/skills, codex: .codex-prompts/, generic: .mcp-prompts/).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "client": "<client>"
    },
    "name": "delivery_generate_agent_pack"
  }
}

Input Schema

Name	Required	Description	Default
`client`	Yes
`repoPath`	No	Repository to write the pack into	.
`overwrite`	No	Replace files that already exist

Output Schema

Name	Required	Description	Default
`tool`	Yes
`issueKey`	No
`markdown`	Yes
`warnings`	Yes
`schemaVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Oct 24, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructive=true and idempotent=true, so the safety profile is covered. The description adds genuinely useful context by mapping each client enum to its on-disk directory, but it never warns that existing files can be replaced or clarifies how destructive behavior interacts with `overwrite`.

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?

A single sentence with the action front-loaded and the client-to-path mapping in a compact parenthetical. The parenthetical is dense but each clause carries real information, no filler.

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 no explanation, and the three parameters are largely covered by schema plus the description's path mapping. For a small write tool with strong annotations, an agent has enough to invoke it correctly.

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 67% and documents `repoPath` and `overwrite`. The description goes further than the schema by spelling out the filesystem destination for every `client` value, which the bare enum does not convey. It still says nothing about what the generated pack contains, but that is outside parameter scope.

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 ('Write reusable Jira delivery prompts/commands ... into the repository') plus the concrete target directories per client. An agent can tell it produces files, but nothing distinguishes it from the sibling `delivery_generate`, which sounds closely related.

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?

No when-to-use statement, no prerequisites (e.g. must a work brief exist first?), and no mention of the sibling `delivery_generate` as the alternative. The agent must infer timing from the tool name alone.

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

Deploy Server