Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

Zephyr: Update Test Cycle

zephyr_update_test_cycle
Idempotent

Update a Zephyr test cycle by merging changes, preventing accidental property removal. Modify name, dates, status, folder, owner, or custom fields.

Instructions

Update an existing Test Cycle in Zephyr. This operation fetches the current test cycle and merges your updates with it to prevent accidental property deletion. To remove a property, set it to null explicitly. The plannedStartDate and plannedEndDate fields cannot be cleared

Toolset: Test Cycles

Examples:

  1. Update the name of the test cycle 'SA-R40' to 'Sprint 1 Regression - Updated' and set description.

{
  "testCycleIdOrKey": "SA-R40",
  "name": "Sprint 1 Regression - Updated",
  "description": "Updated regression scope for Sprint 1"
}

Expected Output: The test cycle should be updated, but no output is expected.

  1. Update planned dates for test cycle id '1' (keep everything else unchanged).

{
  "testCycleIdOrKey": "1",
  "plannedStartDate": "2018-05-19T13:15:13Z",
  "plannedEndDate": "2018-05-20T13:15:13Z"
}

Expected Output: The test cycle should be updated, but no output is expected.

  1. Change folder and status for test cycle 'SA-R40' by setting folder id and status id.

{
  "testCycleIdOrKey": "SA-R40",
  "folder": {
    "id": 100006
  },
  "status": {
    "id": 10000
  }
}

Expected Output: The test cycle should be updated, but no output is expected.

  1. Update custom fields on test cycle 'SA-R40' while keeping other custom fields intact.

{
  "testCycleIdOrKey": "SA-R40",
  "customFields": {
    "Build Number": 20,
    "Release Date": "2020-01-01"
  }
}

Expected Output: The test cycle should be updated, but no output is expected.

  1. Remove the owner from test cycle 'SA-R40'.

{
  "testCycleIdOrKey": "SA-R40",
  "owner": null
}

Expected Output: The test cycle should be updated, but no output is expected.

  1. Remove a specific custom field 'Pre-Condition(s)' from test cycle 'SA-R40' while keeping other custom fields intact.

{
  "testCycleIdOrKey": "SA-R40",
  "customFields": {
    "Pre-Condition(s)": null,
    "Implemented": false
  }
}

Expected Output: The test cycle should be updated, but no output is expected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe ID of the entity
keyNoUnique key of the test cycle
nameNo
ownerNoAtlassian Account ID of the Jira user.
folderNoID and link to the folder resource.
statusNoID and link to the status resource.
projectNoID and link relative to Zephyr project.
descriptionNoDescription outlining the scope.
customFieldsNoMulti-line text fields support HTML and should denote new lines with the \<br\> tag. Dates should be in the format 'yyyy-MM-dd'. Users should have values of Jira User Account IDs.
plannedEndDateNoThe planned end date of the test cycle. This field cannot be blank. Setting it as null or excluding it from the request will leave the field values unchanged. ISO 8601 Format (i.e., yyyy-MM-dd'T'HH:mm:ss'Z')
plannedStartDateNoPlanned start date of the test cycle. This field cannot be blank. Setting it as null or excluding it from the request will leave the field values unchanged. ISO 8601 Format (i.e., yyyy-MM-dd'T'HH:mm:ss'Z')
testCycleIdOrKeyYesThe ID or key of the test cycle.
jiraProjectVersionNoID and Link to fetch information about Jira Project version. Relates to 'Version' or 'Releases' in Jira projects.
Behavior4/5

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

The description explains the behavioral trait of merging updates (fetching current then applying changes), which aligns with the idempotentHint annotation (repeated calls have same effect). It also discloses that planned date fields cannot be cleared. There is no contradiction with annotations. The description adds useful context beyond the annotations.

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?

The description is well-structured: a concise opening statement, followed by key behavioral notes, then six clear examples. While slightly lengthy due to examples, each example serves a purpose (name update, dates, folder/status, custom fields, null removal, custom field null removal). The front-loaded key information is effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (13 parameters, nested objects, no output schema), the description is complete enough. It covers the essential update behavior, null handling, and field restrictions. The examples fill gaps for common scenarios. The absence of output schema is acceptable as update operations often return no data. Sibling context shows this is one of many Zephyr tools, but the description adequately defines this tool's scope.

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?

With 92% schema description coverage, the schema already documents all 13 parameters thoroughly. The description adds value primarily through explaining overall behavior (merge, null handling) and providing examples that demonstrate parameter usage. However, it does not add per-parameter semantic details beyond what the schema provides, so baseline 3 is appropriate.

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 clearly states the tool updates an existing test cycle ('Update an existing Test Cycle in Zephyr'). It also explains the merge behavior and specific constraints, making the purpose concrete. While it does not explicitly differentiate from sibling tools like create or get, the verb 'Update' and resource 'Test Cycle' are unambiguous.

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 direct guidance on when to use this tool (updating a test cycle) and important usage details: merging updates to prevent accidental deletion, setting null to remove properties, and the inability to clear planned dates. The examples further illustrate typical use cases. However, it does not compare with alternative tools like creation or deletion.

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/SmartBear/smartbear-mcp'

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