Testiny Test Management

List Testiny test cases

listTestCases

Read-onlyIdempotent

Retrieve a list of Testiny test cases with an optional keyword filter and an optional folder filter

Input Schema

Name	Required	Description
`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.
`keyword`	No	An optional keyword to search in test case titles. A keyword of digits only, optionally prefixed 'TC-' or '#', looks up that id instead of searching titles.
`project`	Yes	Project ID (number or string), project key or part of the project name
`folderKeyword`	No	An optional keyword to search in test case folder titles. A keyword of digits only, optionally prefixed 'TCF-' or '#', looks up that id instead of searching titles.

Output Schema

Name	Required	Description	Default
`testCases`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedOct 12, 2026

changedInput schema / properties / folderKeyword / description

Previous value: -"An optional keyword to search in test case folder titles. When looking for an id, search in the following format: TCF-1234"New value: +"An optional keyword to search in test case folder titles. A keyword of digits only, optionally prefixed 'TCF-' or '#', looks up that id instead of searching titles."

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"
+}

changedInput schema / properties / keyword / description

Previous value: -"An optional keyword to search in test case titles. When looking for an id, search in the following format: TC-1234"New value: +"An optional keyword to search in test case titles. A keyword of digits only, optionally prefixed 'TC-' or '#', looks up that id instead of searching titles."

addedOutput schema / properties / testCases / items / 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"
+}

addedOutput schema / properties / testCases / items / properties / bddScenarios

Added value: +{
+  "description": "Gherkin source of a BDD test case as it was written, with LF line ends (a carriage return is dropped on write). Plain text in every format, so it is unaffected by 'format'. Omitted unless the template is BDD.",
+  "type": "string"
+}

removedOutput schema / properties / testCases / items / properties / expectedResults
```
Removed value: -{
-  "type": "string"
-}
```

addedOutput schema / properties / testCases / items / properties / steps / description

Added value: +"The STEPS-template content as step + expectedResult pairs, under the same names 'createTestCase' and 'editTestCase' take, each cell in the requested format. Omitted for TEXT and BDD test cases, and for cases without content."

addedOutput schema / properties / testCases / items / properties / steps / items

Added value: +{
+  "properties": {
+    "expectedResult": {
+      "description": "The expected-result cell, in the requested format",
+      "type": "string"
+    },
+    "index": {
+      "description": "0-based step index",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "step": {
+      "description": "The step action cell, in the requested format",
+      "type": "string"
+    }
+  },
+  "required": [
+    "index",
+    "step",
+    "expectedResult"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / testCases / items / properties / steps / type
```
Previous value: -"string"New value: +"array"
```

changedOutput schema / properties / testCases / items / properties / template / description

Previous value: -"The template type of the test case, e.g. STEPS, TEXT (converted to STEPS on edit), BDD (editing currently not supported)"New value: +"The content template the test case displays: STEPS (interleaved action/expected-result steps), TEXT (free-form documents) or BDD (gherkin scenarios)"

addedOutput schema / properties / testCases / items / properties / template / enum
```
Added value: +[
+  "TEXT",
+  "STEPS",
+  "BDD"
+]
```

addedOutput schema / properties / testCases / items / properties / text

Added value: +{
+  "description": "The TEXT-template content, under the same names 'createTestCase' and 'editTestCase' take. Omitted unless the template is TEXT.",
+  "properties": {
+    "expectedResultText": {
+      "description": "The expected-result document, in the requested format",
+      "type": "string"
+    },
+    "stepsText": {
+      "description": "The steps/actions document, in the requested format",
+      "type": "string"
+    }
+  },
+  "required": [
+    "stepsText",
+    "expectedResultText"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / testCases / items / required

Previous value: -[
-  "id",
-  "title",
-  "folder",
-  "precondition",
-  "template"
-]New value: +[
+  "id",
+  "title",
+  "folder",
+  "template",
+  "precondition",
+  "_etag"
+]

First observedOct 2, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing behavioral beyond that: no pagination/result-cap, no default ordering, no scope limits, only a restatement of the filters already in the schema.

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 efficient sentence with the core action front-loaded and no filler. It is appropriately sized, though it is terse enough to omit useful scoping detail.

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

Completeness3/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 not be explained, and both annotations and the 100%-covered schema carry most of the load. What remains missing is any usage/permission context or note about result volume and pagination, leaving the definition minimally viable rather than complete.

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 description coverage is 100%, so the schema already fully documents all four parameters, including the id-lookup behavior of keyword/folderKeyword and the rich-text format rules. The description's mention of the two filters adds no meaning beyond the schema. Baseline 3 applies.

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 gives a clear verb+resource ('Retrieve a list of Testiny test cases') and names the two filter dimensions. It does not explicitly distinguish itself from sibling list tools (listTestCaseFolders, listTestRuns, listProjects), but the resource noun makes the target unambiguous.

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?

There is no guidance on when to use this tool versus listTestCaseFolders, listProjects, or listTestRuns, nor any stated prerequisites or exclusions. The filters are merely listed, leaving the agent to infer the selection context.

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?