Testiny Test Management

by io.testiny

Overview Discussions Admin

Server Details

Create and manage test cases, test runs and results in Testiny from your AI assistant.

Ownership verified

Status: Healthy
Uptime: 17.5% over 56 days
OAuth: Works in Glama
Last Tested: 2026-10-12 14:46
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A3.8/5.0

Scored 2026-10-02 10:30 across 15 tools

Disambiguation5/5

Every tool has a distinct verb+resource focus: folder, test case, test run, result, comment, or project. The single vs batch result tools (setTestResult, setTestResultBatch) are clearly differentiated by name and description. No overlapping purposes that would cause misselection.

Naming Consistency5/5

All 15 tool names use consistent camelCase with a verb_noun pattern (createFolder, editTestCase, listTestRuns, etc.). No mixed conventions or vague non-verb names are present.

Tool Count5/5

15 tools fit the test management domain well, covering projects, folders, test cases, test runs, results, and comments. Each tool earns its place; there is no obvious bloat or too-thin surface.

Completeness3/5

Core CRUD is partially covered: create/read/update exist for test cases and folders, and results can be set and retrieved. However, there are no delete operations for test cases, folders, test runs, or results, and no direct get-by-id for test cases or runs, which are notable lifecycle gaps.

Available Tools

15 tools

addTestResultCommentAdd a comment to the result for a test case in a test runInspect

Adds a comment to the result for a test case in a test run, the test case must already be part of the test run

ParametersJSON 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.
`project`	Yes	Project ID (number or string), project key or part of the project name
`testRunId`	Yes	The id of the test run
`testCaseId`	Yes	The id of the test case in the test run to add the comment to
`commentText`	Yes	The comment text - rich text in the chosen 'format'

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes

createFolderCreate a new test case folderInspect

Creates a new test case folder in a project, optionally nested under an existing folder.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	The title of the new folder
`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
`description`	No	An optional description for the folder - rich text in the chosen 'format'
`parentFolder`	No	Optional parent folder: title substring, numeric id, or ID-format like TCF-123. Omit or leave empty to create at root level - use 'moveFolder' with targetParentId=0 to move it back to the root later.

Output Schema

ParametersJSON 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

createTestCaseCreate a new test caseInspect

Creates a new test case in a given project with an optional precondition, optional folder and optional custom fields. Use the 'template' field to choose the content template: STEPS (interleaved 'steps' of action + expected result), TEXT (free-form 'text.stepsText' and 'text.expectedResultText' documents) or BDD ('bddScenarios' gherkin source). Provide the content for exactly one of them: a content field the chosen template does not display is rejected (status "content_does_not_match_template") rather than stored where nobody sees it.

ParametersJSON Schema

Name	Required	Description
`text`	No	Content for the TEXT template, as two free-form documents. A test case normally uses EITHER the top-level STEPS 'steps' array OR this TEXT content, not both; the 'template' field decides which is shown.
`steps`	No	The STEPS-template steps (interleaved action + expected result per step). Use this OR the TEXT 'text' content, not both. Omit if the test case has no steps.
`title`	Yes	The title of the test case, descriptive but not too long
`folder`	No	The test case folder title or key or ID. If multiple folders match, the first one is used. If omitted, the test case is created in no folder - use 'moveTestCases' with targetFolderId=0 to put it back there later.
`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
`template`	No	Which content template to display: "STEPS" for interleaved action/expected-result steps, "TEXT" for free-form actions and expected-result documents, "BDD" for gherkin scenarios. Defaults to STEPS, or to the template of whichever single content field is provided. Provide content for the chosen template only - content another template would display is rejected, not stored invisibly.
`bddScenarios`	No	Content for the BDD template. Gherkin source for the BDD template - feature/scenario lines as plain text, exactly as a .feature file would carry them. Always plain gherkin regardless of 'format', and it is not parsed or validated, so malformed gherkin is stored as sent. A top-level `Feature:` line is optional - scenarios on their own are fine. A `# language:` directive is honored; otherwise the dialect is detected from the keywords.
`customFields`	No	Custom field values to set, keyed by the 'propName' that listProjects reports for the project - custom fields carry a 'cf__' prefix, built-in ones do not. A bare name or a single-underscore 'cf_' prefix is accepted too, but a key that is itself a propName always means that field.
`precondition`	No	An optional precondition for the test case - rich text in the chosen 'format'

Output Schema

ParametersJSON 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.
`status`	Yes
`testCaseId`	No

createTestRunCreate a new test runInspect

Create a new empty test run where test cases with results and comments can be added

ParametersJSON Schema

Name	Required	Description
`title`	Yes	The title of the test run (e.g. "Regression test release v1.2.3", "Feature test XYZ")
`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
`description`	No	An optional description of the test run - rich text in the chosen 'format'

Output Schema

ParametersJSON Schema

Name	Required	Description
`title`	Yes
`testRunId`	Yes

editFolderUpdate a test case folder

DestructiveIdempotent

Inspect

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.

ParametersJSON 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

ParametersJSON 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

editTestCaseEdit an existing test case

Destructive

Inspect

Partially updates an existing test case. Only the fields provided are changed; omitted fields are left as-is. STEPS content: 'steps' can be individually replaced or deleted by 0-based index, and new steps appended. TEXT content: set 'text.stepsText' / 'text.expectedResultText' (empty string clears, omit keeps). BDD content: set 'bddScenarios' to gherkin source (empty string clears, omit keeps). The 'template' field switches which content is displayed; every template's content is preserved. Content must belong to the displayed template: writing 'steps' to a TEXT/BDD case (or vice versa) is rejected with status "content_does_not_match_template" and nothing is written - pass 'template' in the same call to switch first. Pass the '_etag' from the last read to have the edit rejected instead of overwriting a change somebody else made in the meantime.

ParametersJSON Schema

Name	Required	Description
`text`	No	Updates for the TEXT-template content. A test case normally uses EITHER the STEPS 'steps' array OR this TEXT content; 'template' selects which is shown. Omitted fields are kept.
`_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.
`steps`	No	Partial updates for the STEPS-template steps. Every index refers to the original step list and is unaffected by deletions in the same call. Steps with delete=true are removed; others replace or append at that index. Only apply necessary updates.
`title`	No	New title for the test case. 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
`template`	No	Switch which content template is displayed: "STEPS", "TEXT" or "BDD". Omit to keep the current one. Switching deletes no content - the other templates keep theirs, and switching back shows it again. A case switched back to STEPS gets its old steps back, and 'steps' indices refer to those although no read showed them while another template was displayed: switch first, re-read, then edit the steps. Content fields in this call are checked against the template set here (or the current one when omitted), so set it in the same call to write another template's content.
`testCaseId`	Yes	The id of the test case to edit
`bddScenarios`	No	New BDD-template content. Omit to keep it, pass an empty string to clear it. Gherkin source for the BDD template - feature/scenario lines as plain text, exactly as a .feature file would carry them. Always plain gherkin regardless of 'format', and it is not parsed or validated, so malformed gherkin is stored as sent. A top-level `Feature:` line is optional - scenarios on their own are fine. A `# language:` directive is honored; otherwise the dialect is detected from the keywords.
`customFields`	No	Custom field values to update, keyed by the 'propName' that listProjects reports - custom fields carry a 'cf__' prefix, built-in ones do not (a bare name or a single-underscore 'cf_' prefix is accepted too, but a key that is itself a propName always means that field). Only provided fields are changed.
`precondition`	No	New precondition text - rich text in the chosen 'format'. Pass an empty string to clear it. Omit to keep the existing precondition.

Output Schema

ParametersJSON 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.
`status`	Yes
`testCaseId`	No

getTestStatusFetch test result information for test cases in a test run

Read-onlyIdempotent

Inspect

Gets test case results, step results, comments and the assignee for all test cases or a specific one in a test run

ParametersJSON 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.
`project`	Yes	Project ID (number or string), project key or part of the project name
`testRunId`	Yes	The id of the test run
`testCaseId`	No	The id of the test case in the test run to get the status for. If not specified, the status for all test cases in the test run are returned

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`testCases`	No
`testRunId`	Yes
`testRunIsClosed`	No

listProjectsList Testiny projects

Read-onlyIdempotent

Inspect

Retrieve a list of all accessible Testiny projects, each with the custom fields configured for it. 'customFields' covers two kinds, told apart by their 'entity': fields a test case carries ('testcase') and fields a test result carries ('testresult', including 'result_status'). Filter by 'entity' before using them.

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	No	An optional keyword to search for projects, omitting will return all projects

Output Schema

ParametersJSON Schema

Name	Required	Description
`projects`	Yes

listTestCaseFoldersList Testiny test case folders

Read-onlyIdempotent

Inspect

Retrieve a list of Testiny test case folders with an optional keyword filter

ParametersJSON 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 folder titles. A keyword of digits only, optionally prefixed 'TCF-' or '#', looks up that id instead of searching titles.
`project`	Yes	Project ID (number or string), project key or part of the project name

Output Schema

ParametersJSON Schema

Name	Required	Description
`testCaseFolders`	Yes

listTestCasesList Testiny test cases

Read-onlyIdempotent

Inspect

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

ParametersJSON 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

ParametersJSON Schema

Name	Required	Description
`testCases`	Yes

listTestRunsList Testiny test runs

Read-onlyIdempotent

Inspect

Retrieve a list of Testiny test runs with an optional keyword filter

ParametersJSON 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 run titles. A keyword of digits only, optionally prefixed 'TR-' or '#', looks up that id instead of searching titles.
`project`	Yes	Project ID (number or string), project key or part of the project name

Output Schema

ParametersJSON Schema

Name	Required	Description
`testRuns`	Yes

moveFolderMove a test case folder

Idempotent

Inspect

Moves a test case folder to a different parent folder. Use targetParentId=0 to move it to root level. Rejects moves that would create a circular hierarchy. A move changes the folder's '_etag' and returns the new one - pass that to a later 'editFolder'.

ParametersJSON Schema

Name	Required	Description
`project`	Yes	Project ID (number or string), project key or part of the project name
`folderId`	Yes	The id of the folder to move
`targetParentId`	Yes	The id of the target parent folder. Use 0 to move the folder to the root level.

Output Schema

ParametersJSON 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.
`status`	Yes
`folderId`	No

moveTestCasesMove test cases into a folderA

Idempotent

Inspect

Moves one or more test cases into a target folder, replacing their current folder assignment. Use targetFolderId=0 to remove them from any folder.

ParametersJSON Schema

Name	Required	Description
`project`	Yes	Project ID (number or string), project key or part of the project name
`testCaseIds`	Yes	The ids of the test cases to move
`targetFolderId`	Yes	The id of the target folder. Use 0 to remove the test cases from any folder.

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`movedCount`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare it is a non-destructive, idempotent write (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds real behavioral context by clarifying that the move replaces the existing folder assignment rather than creating a second membership, which is not implied by 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the core action, with the edge-case behavior appended compactly. No padding or 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 and annotations cover the safety profile, so return values and mutation safety need no restating. The description covers the essential mutation semantics; only the sibling-relationship and permission context are missing.

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 all three parameters are documented in the schema, including the targetFolderId=0 convention. The description merely restates that convention, adding no syntax or format detail 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?

States a specific verb (moves) and resource (test cases) plus the effect on assignment (replacing their current folder). However, it does not differentiate from the sibling moveFolder, which an agent could confuse with this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one actionable usage rule (targetFolderId=0 removes the cases from any folder), but offers no guidance on when to choose this over moveFolder or any prerequisites such as permissions or folder existence.

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

setTestResultSet the result for a given test case in a test run

DestructiveIdempotent

Inspect

Sets the result for a given test case in a test run and adds the test case to the test run if it was not part of the test run yet

ParametersJSON Schema

Name	Required	Description
`project`	Yes	Project ID (number or string), project key or part of the project name
`testRunId`	Yes	The id of the test run
`testCaseId`	Yes	The id of the test case in the test run to add/update the status for
`testResult`	Yes	The result of the test case. The builtin values 'passed', 'failed', 'blocked', 'skipped' and 'notrun' are case-insensitive, so 'passed' and 'PASSED' are the same. A project can also define extra result statuses - listProjects reports those under the 'result_status' field, and they must be spelled exactly as reported. Use 'notrun' if you only want to add the test case to the run without assigning a result

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes

setTestResultBatchSet the result for multiple test cases in a test run

DestructiveIdempotent

Inspect

Sets the result for multiple test cases in a test run and adds the test cases to the test run if they were not part of the test run yet

ParametersJSON Schema

Name	Required	Description
`project`	Yes	Project ID (number or string), project key or part of the project name
`results`	Yes
`testRunId`	Yes	The id of the test run

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

13 tool updatesOct 12, 2026

ChangedaddTestResultComment3 fields changed

changedInput schema / properties / commentText / description

Previous value: -"The comment text - can include simple markdown elements"New value: +"The comment text - rich text in the chosen 'format'"

changedInput schema / properties / commentText / maxLength
```
Previous value: -32000New value: +16000
```

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

ChangedcreateFolder4 fields changed

changedInput schema / properties / description / description

Previous value: -"An optional description for the folder - can include simple markdown"New value: +"An optional description for the folder - rich text in the chosen 'format'"

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 / parentFolder / description

Previous value: -"Optional parent folder: title substring, numeric id, or ID-format like TCF-123. Omit or leave empty to create at root level."New value: +"Optional parent folder: title substring, numeric id, or ID-format like TCF-123. Omit or leave empty to create at root level - use 'moveFolder' with targetParentId=0 to move it back to the root later."

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

ChangedcreateTestCase14 fields changed

addedInput schema / properties / bddScenarios

Added value: +{
+  "description": "Content for the BDD template. Gherkin source for the BDD template - feature/scenario lines as plain text, exactly as a .feature file would carry them. Always plain gherkin regardless of 'format', and it is not parsed or validated, so malformed gherkin is stored as sent. A top-level `Feature:` line is optional - scenarios on their own are fine. A `# language:` directive is honored; otherwise the dialect is detected from the keywords.",
+  "maxLength": 32000,
+  "type": "string"
+}

addedInput schema / properties / customFields / description

Added value: +"Custom field values to set, keyed by the 'propName' that listProjects reports for the project - custom fields carry a 'cf__' prefix, built-in ones do not. A bare name or a single-underscore 'cf_' prefix is accepted too, but a key that is itself a propName always means that field."

changedInput schema / properties / folder / description

Previous value: -"The test case folder title or key or ID. If multiple folders match, the first one is used. If omitted, the test case is created in the root folder."New value: +"The test case folder title or key or ID. If multiple folders match, the first one is used. If omitted, the test case is created in no folder - use 'moveTestCases' with targetFolderId=0 to put it back there later."

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 / precondition / description

Previous value: -"An optional precondition for the test case - can include simple markdown"New value: +"An optional precondition for the test case - rich text in the chosen 'format'"

changedInput schema / properties / precondition / maxLength
```
Previous value: -8000New value: +16000
```

changedInput schema / properties / steps / description

Previous value: -"A record of custom field values to set on the test case, the properties must match existing custom field names in the project. "New value: +"The STEPS-template steps (interleaved action + expected result per step). Use this OR the TEXT 'text' content, not both. Omit if the test case has no steps."

changedInput schema / properties / steps / items / properties / expectedResult / description

Previous value: -"The expected result for this step - can include simple markdown"New value: +"The expected result for this step - rich text in the chosen 'format'"

changedInput schema / properties / steps / items / properties / expectedResult / maxLength
```
Previous value: -8000New value: +16000
```

changedInput schema / properties / steps / items / properties / step / description

Previous value: -"A single step in the test case - can include simple markdown"New value: +"A single step in the test case - rich text in the chosen 'format'"

changedInput schema / properties / steps / items / properties / step / maxLength
```
Previous value: -8000New value: +16000
```

addedInput schema / properties / template

Added value: +{
+  "description": "Which content template to display: \"STEPS\" for interleaved action/expected-result steps, \"TEXT\" for free-form actions and expected-result documents, \"BDD\" for gherkin scenarios. Defaults to STEPS, or to the template of whichever single content field is provided. Provide content for the chosen template only - content another template would display is rejected, not stored invisibly.",
+  "enum": [
+    "TEXT",
+    "STEPS",
+    "BDD"
+  ],
+  "type": "string"
+}

addedInput schema / properties / text

Added value: +{
+  "description": "Content for the TEXT template, as two free-form documents. A test case normally uses EITHER the top-level STEPS 'steps' array OR this TEXT content, not both; the 'template' field decides which is shown.",
+  "properties": {
+    "expectedResultText": {
+      "description": "The TEXT-template expected-result document - one free-form rich-text document",
+      "maxLength": 32000,
+      "type": "string"
+    },
+    "stepsText": {
+      "description": "The TEXT-template steps/actions document - one free-form rich-text document, unrelated to the top-level 'steps' array",
+      "maxLength": 32000,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

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

ChangedcreateTestRun2 fields changed

changedInput schema / properties / description / description

Previous value: -"An optional description of the test run - can include simple markdown"New value: +"An optional description of the test run - rich text in the chosen 'format'"

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

ChangededitFolder4 fields changed

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

ChangededitTestCase15 fields changed

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

addedInput schema / properties / bddScenarios

Added value: +{
+  "description": "New BDD-template content. Omit to keep it, pass an empty string to clear it. Gherkin source for the BDD template - feature/scenario lines as plain text, exactly as a .feature file would carry them. Always plain gherkin regardless of 'format', and it is not parsed or validated, so malformed gherkin is stored as sent. A top-level `Feature:` line is optional - scenarios on their own are fine. A `# language:` directive is honored; otherwise the dialect is detected from the keywords.",
+  "maxLength": 32000,
+  "type": "string"
+}

addedInput schema / properties / customFields / description

Added value: +"Custom field values to update, keyed by the 'propName' that listProjects reports - custom fields carry a 'cf__' prefix, built-in ones do not (a bare name or a single-underscore 'cf_' prefix is accepted too, but a key that is itself a propName always means that field). Only provided fields are changed."

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 / precondition / description

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

changedInput schema / properties / precondition / maxLength
```
Previous value: -8000New value: +16000
```

changedInput schema / properties / steps / description

Previous value: -"Custom field values to update. Only provided fields are changed; omit a field to leave it unchanged."New value: +"Partial updates for the STEPS-template steps. Every index refers to the original step list and is unaffected by deletions in the same call. Steps with delete=true are removed; others replace or append at that index. Only apply necessary updates."

changedInput schema / properties / steps / items / properties / expectedResult / description

Previous value: -"New expected result for the step. Omit to keep the existing expected result."New value: +"New expected result for the step. Omit to keep the existing expected result. Empty string *deletes* current content."

changedInput schema / properties / steps / items / properties / expectedResult / maxLength
```
Previous value: -8000New value: +16000
```

changedInput schema / properties / steps / items / properties / index / description

Previous value: -"0-based index of the step in the original step list. Use a value >= current step count to append a new step."New value: +"0-based index into the step list as it stood before this call. Use a value >= the original step count to append a new step; an appended cell that is omitted is stored empty."

changedInput schema / properties / steps / items / properties / step / description

Previous value: -"New content for the step action. Omit to keep the existing step content."New value: +"New content for the step action. Omit to keep the existing step content. Empty string *deletes* current content."

changedInput schema / properties / steps / items / properties / step / maxLength
```
Previous value: -8000New value: +16000
```

addedInput schema / properties / template

Added value: +{
+  "description": "Switch which content template is displayed: \"STEPS\", \"TEXT\" or \"BDD\". Omit to keep the current one. Switching deletes no content - the other templates keep theirs, and switching back shows it again. A case switched back to STEPS gets its old steps back, and 'steps' indices refer to those although no read showed them while another template was displayed: switch first, re-read, then edit the steps. Content fields in this call are checked against the template set here (or the current one when omitted), so set it in the same call to write another template's content.",
+  "enum": [
+    "TEXT",
+    "STEPS",
+    "BDD"
+  ],
+  "type": "string"
+}

addedInput schema / properties / text

Added value: +{
+  "description": "Updates for the TEXT-template content. A test case normally uses EITHER the STEPS 'steps' array OR this TEXT content; 'template' selects which is shown. Omitted fields are kept.",
+  "properties": {
+    "expectedResultText": {
+      "description": "New TEXT-template expected-result document - one free-form rich-text document. Omit to keep it, pass an empty string to clear it.",
+      "maxLength": 32000,
+      "type": "string"
+    },
+    "stepsText": {
+      "description": "New TEXT-template steps/actions document - one free-form rich-text document, unrelated to the top-level 'steps' array. Omit to keep it, pass an empty string to clear it.",
+      "maxLength": 32000,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

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

ChangedgetTestStatus2 fields changed

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 / testCases / items / properties / assigneeName

Added value: +{
+  "description": "The display name of the user the test case is assigned to in this run, omitted when not assigned.",
+  "type": "string"
+}

ChangedlistTestCaseFolders4 fields changed

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 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."

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

changedOutput schema / properties / testCaseFolders / items / required

Previous value: -[
-  "id",
-  "title",
-  "parent",
-  "description"
-]New value: +[
+  "id",
+  "title",
+  "parent",
+  "description",
+  "_etag"
+]

ChangedlistTestCases13 fields changed

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

ChangedlistTestRuns4 fields changed

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 run titles. When looking for an id, search in the following format: TR-1234"New value: +"An optional keyword to search in test run titles. A keyword of digits only, optionally prefixed 'TR-' or '#', looks up that id instead of searching titles."

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

changedOutput schema / properties / testRuns / items / required

Previous value: -[
-  "id",
-  "title",
-  "testplan",
-  "description",
-  "isClosed"
-]New value: +[
+  "id",
+  "title",
+  "testplan",
+  "description",
+  "isClosed",
+  "_etag"
+]

ChangedmoveFolder1 field changed

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

ChangedsetTestResult1 field changed

changedInput schema / properties / testResult / description

Previous value: -"The result of the test case. Builtin values include 'passed', 'failed', 'blocked', 'skipped' and 'notrun', other values can be allowed if configured. Use 'notrun' if you only want to add the test case to the run without assigning a result"New value: +"The result of the test case. The builtin values 'passed', 'failed', 'blocked', 'skipped' and 'notrun' are case-insensitive, so 'passed' and 'PASSED' are the same. A project can also define extra result statuses - listProjects reports those under the 'result_status' field, and they must be spelled exactly as reported. Use 'notrun' if you only want to add the test case to the run without assigning a result"

ChangedsetTestResultBatch1 field changed

changedInput schema / properties / results / items / properties / testResult / description

Previous value: -"The result of the test case. Builtin values include 'passed', 'failed', 'blocked', 'skipped' and 'notrun', other values can be allowed if configured. Use 'notrun' if you only want to add the test case to the run without assigning a result"New value: +"The result of the test case. The builtin values 'passed', 'failed', 'blocked', 'skipped' and 'notrun' are case-insensitive, so 'passed' and 'PASSED' are the same. A project can also define extra result statuses - listProjects reports those under the 'result_status' field, and they must be spelled exactly as reported. Use 'notrun' if you only want to add the test case to the run without assigning a result"

15 tool updatesOct 2, 2026
- First observedaddTestResultComment
- First observedcreateFolder
- First observedcreateTestCase
- First observedcreateTestRun
- First observededitFolder
- First observededitTestCase
- First observedgetTestStatus
- First observedlistProjects
- First observedlistTestCaseFolders
- First observedlistTestCases
- First observedlistTestRuns
- First observedmoveFolder
- First observedmoveTestCases
- First observedsetTestResult
- First observedsetTestResultBatch

Publisher details

Operator: Mategra GmbH · Publisher source
Operator website: https://www.testiny.io/ · Publisher source
Vendor relationship: First-party · Publisher source
Documentation: https://www.testiny.io/docs/mcp-server/ · Publisher source
Trust center: Not available
Restrictions: Requires a paid plan or active trial. · Publisher source

Related MCP Connectors

MeisterTaskOAuth
com.meistertask
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
Project Management Workplace & Productivity
2
Cypress Cloud MCP BOAuth
io.cypress.mcp
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Testing & QA Tools CI/CD & DevOps
24
mcp-server
com.testrigor
Manage test suites, run tests, view results, and automate QA workflows via AI with testRigor.
Testing & QA Tools App Automation
2
Loom
io.github.abhinand-adviciya
Manage Loom projects, tasks, bugs, defects, clients and phases from AI assistants
Project Management Testing & QA Tools
1

Related MCP Servers

Testmo MCP Server
Testing & QA Tools Project Management
filipljoljic
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Testmo test management platform for creating, reading, updating, and deleting test cases, managing folders, and organizing test runs through natural language.
Updated 10 months ago (2025-12-01 14:22 UTC)
4
MIT
TestCollab MCP Server
Testing & QA Tools Developer Tools
TCSoftInc
A
license
A
quality
B
maintenance
Connects AI coding assistants to TestCollab for managing test cases, plans, and suites directly through natural language. It enables users to create, update, and query testing resources within integrated development environments and AI chat clients.
Updated a month ago (2026-08-27 22:28 UTC)
17
106 npm
4
MIT
TestRail MCP Server
Testing & QA Tools Developer Tools
denys-ispaniuk
A
license
B
quality
D
maintenance
Enables AI assistants to interact with TestRail test management system, supporting full CRUD operations on projects, suites, sections, test cases, runs, results, plans, and milestones.
Updated a year ago (2025-10-17 16:31 UTC)
35
154 npm
1
MIT
TestRail MCP Server
Testing & QA Tools API Testing
Derrbal
A
license
B
quality
D
maintenance
Enables AI assistants to interact with TestRail test management systems through comprehensive API integration. Supports retrieving and updating test cases, projects, suites, runs, and results, plus adding attachments and managing test data through natural language commands.
Updated 6 months ago (2026-03-28 12:24 UTC)
18
20 npm
MIT

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?

Server Details

TDQS

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

TDQS

Output Schema

Output Schema

Tool Schema Changelog

Publisher details

Related MCP Connectors

Related MCP Servers

Testmo MCP Server

TestCollab MCP Server

TestRail MCP Server

TestRail MCP Server

Glama MCP Gateway

Resources