Skip to main content
Glama

update_test_plan

Idempotent

Update a Jira test plan with a partial update: only provided fields change, omitted fields keep current values. Use for changing name, owner, folder, status, objective, labels, or issue links.

Instructions

Update a test plan (PUT /testplan/{testPlanKey}). PARTIAL update: only the fields you pass are written and omitted fields keep their current value, so never send empty placeholders — they overwrite real data. projectKey cannot be changed. folder must be a TEST_PLAN folder (create_folder with type TEST_PLAN) — The folder MUST already exist — the API never creates folders implicitly (use create_folder first). status is a case-sensitive internal name. owner: Jira user key (e.g. 'JIRAUSER10000'), NOT a username or e-mail — resolve it with find_jira_user. Returns { key }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoTest plan name
ownerNoOwner. Jira *user key* (e.g. 'JIRAUSER10000'), NOT a username or e-mail — resolve it with find_jira_user.
folderNoFull path of a TEST_PLAN folder from the root starting with "/", e.g. "/Releases/2026". The folder MUST already exist — the API never creates folders implicitly (use create_folder first).
labelsNoLabels; the API replaces spaces with underscores
statusNoTest plan status. Defaults: 'Draft', 'Approved', 'Deprecated' — case-sensitive; instances may define custom ones. Plan statuses are their OWN option set: get_status_options cannot list them (it has no test_plan optionSet) and the test CASE statuses it returns are rejected here with 400 "The value <x> was not found for field status."
objectiveNoObjective (HTML allowed)
issueLinksNoJira issue keys to link, e.g. ["PROJ-123"]
testPlanKeyYesTest plan key, e.g. PROJ-P123
customFieldsNoCustom field values keyed by field name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.5

TDQS

A4.7/5.0
Behavior5/5

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

Only idempotentHint is annotated, so the description carries the real burden and does so: it discloses partial-write semantics with an explicit data-loss warning about empty placeholders, immutability of projectKey, the implicit-folder-creation limitation, a specific 400 error mode for wrong status values, and the return shape { key }.

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?

Front-loads verb, endpoint and the critical partial-update rule, and nearly every clause carries a distinct constraint. It is somewhat dense and run-on with stacked em-dash asides, so it is efficient rather than elegant.

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?

For a 9-parameter mutation with nested objects, no output schema and minimal annotations, the description covers prerequisites, immutability, error modes and the return value. An agent has everything needed to call it correctly; the only minor gap is that projectKey is discussed though it is not in the schema.

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

Parameters5/5

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

Schema coverage is 100% (baseline 3), but the description adds meaning the schema alone would not convey reliably: owner is a Jira user key not a username/email, folder must be a TEST_PLAN folder that already exists, status is a case-sensitive internal name from a private option set, and projectKey is immutable. That is genuine additive semantics over the parameter list.

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?

Names a specific verb and resource ('Update a test plan') and even cites the underlying endpoint PUT /testplan/{testPlanKey}, which separates it cleanly from create_test_plan, get_test_plan and delete_test_plan in the sibling list.

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?

Gives strong operational guidance: partial-update semantics, 'never send empty placeholders', folder must pre-exist via create_folder, owner must be resolved with find_jira_user, and status cannot come from get_status_options. It stops short of routing between sibling tools (e.g. when to prefer search_test_plans to find the key or what to do for a full replace), so it is clear context rather than complete when/when-not coverage.

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