Testiny Test Management

Update a test case folder

editFolder

DestructiveIdempotent

Updates the title and/or description of an existing test case folder. Only provided fields are changed. Pass the '_etag' from the last read to have the edit rejected instead of overwriting a change somebody else made in the meantime.

Input Schema

Name	Required	Description
`_etag`	No	Optional conflict tag from the last read or edit of this entity, for a safe read-modify-write: the edit is only applied while nobody else has changed the entity since. Pass it back verbatim, including an empty string. On a mismatch nothing is written and the call answers with status "update_conflict" and the current '_etag' to re-read from. Omit it to overwrite whatever is stored.
`title`	No	New title for the folder. Omit to keep the existing title.
`format`	No	Format for rich-text fields (descriptions, preconditions, comments, step & result cells, stepsText & expectedResultText) on both input and output: 'markdown' (default) or 'xml'. Read the matching rich-text format reference resource before producing either. Use 'xml' for BOTH the read and the write whenever you are changing a field that already has content: markdown cannot carry an underline or a text color, so an edit written as markdown writes those away. 'markdown' is for writing new content and for reading you will not edit.
`project`	Yes	Project ID (number or string), project key or part of the project name
`folderId`	Yes	The id of the folder to update
`description`	No	New description for the folder - rich text in the chosen 'format'. Pass an empty string to clear it. Omit to keep the existing description.

Output Schema

Name	Required	Description
`_etag`	No	Conflict tag of the entity - pass it to an edit tool's '_etag' to have that edit rejected if somebody changed the entity in the meantime. Empty for an entity that carries no tag yet.
`title`	No
`status`	Yes
`folderId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 12, 2026

addedInput schema / properties / _etag

Added value: +{
+  "description": "Optional conflict tag from the last read or edit of this entity, for a safe read-modify-write: the edit is only applied while nobody else has changed the entity since. Pass it back verbatim, including an empty string. On a mismatch nothing is written and the call answers with status \"update_conflict\" and the current '_etag' to re-read from. Omit it to overwrite whatever is stored.",
+  "maxLength": 32,
+  "type": "string"
+}

changedInput schema / properties / description / description

Previous value: -"New description for the folder - can include simple markdown. Pass an empty string to clear it. Omit to keep the existing description."New value: +"New description for the folder - rich text in the chosen 'format'. Pass an empty string to clear it. Omit to keep the existing description."

addedInput schema / properties / format

Added value: +{
+  "description": "Format for rich-text fields (descriptions, preconditions, comments, step & result cells, stepsText & expectedResultText) on both input and output: 'markdown' (default) or 'xml'. Read the matching rich-text format reference resource before producing either. Use 'xml' for BOTH the read and the write whenever you are changing a field that already has content: markdown cannot carry an underline or a text color, so an edit written as markdown writes those away. 'markdown' is for writing new content and for reading you will not edit.",
+  "enum": [
+    "markdown",
+    "xml"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / _etag

Added value: +{
+  "description": "Conflict tag of the entity - pass it to an edit tool's '_etag' to have that edit rejected if somebody changed the entity in the meantime. Empty for an entity that carries no tag yet.",
+  "type": "string"
+}

First observedOct 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations cover the safety profile (destructiveHint=true, idempotentHint=true), and the description adds non-trivial behavior beyond them: partial-update semantics ('only provided fields are changed') and the concurrency rejection outcome when _etag mismatches. It does not itself warn what gets destroyed (e.g., markdown wiping underlines/colors), which lives only in the schema, so it is not a 5.

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?

Short and front-loaded, with the core action stated first and the partial-update and concurrency notes following in logical order. The _etag sentence overlaps heavily with the schema's own _etag description, a minor redundancy.

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?

An output schema exists so return values (including the update_conflict status) need no explanation, and the description covers purpose, partial updates, and conflict handling. The important format/rich-text caveat is only in the schema, leaving a small gap in the description's own coverage of a destructive-capable edit.

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 coverage is 100% and every parameter is documented in detail there, including the _etag, title, description, and format semantics. The description's 'only provided fields are changed' and _etag mention largely restate the schema, so the baseline 3 applies.

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?

States a specific verb (updates) and resource (an existing test case folder) and scopes exactly which fields can change (title and/or description). This cleanly separates it from siblings like createFolder, moveFolder, and editTestCase without needing the schema.

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 clear context: use it to change title/description of an existing folder, and explains the _etag path for a safe read-modify-write versus overwriting. It does not explicitly steer the agent to alternatives (e.g., moveFolder for relocation), which keeps it below a 5.

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

All Testiny Test Management tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?