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: 38.3% over 77 days
OAuth: Works in Glama
Last Tested: 2026-11-02 05:19
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

A3.5/5.0

Scored 2026-10-29 16:00 across 15 tools

Disambiguation4/5

Most tools have clearly distinct purposes, e.g. createTestCase vs editTestCase, moveTestCases vs moveFolder, setTestResult vs setTestResultBatch. The only mild overlap is among the run-scoped result tools (getTestStatus, setTestResult, addTestResultComment), but their read/write/comment roles are distinguishable. An agent can reliably select the right tool from the names and descriptions.

Naming Consistency4/5

Nearly all tools follow a consistent camelCase verb_noun pattern (listTestCases, createFolder, editFolder, moveTestCases, setTestResult). The lone minor deviation is getTestStatus, whose noun doesn't map cleanly to a resource and reads like a status check despite returning results/comments. Otherwise the convention is predictable and readable.

Tool Count5/5

At 15 tools the surface is well-scoped for test management, with each tool earning a distinct role (folder/test-case/run/result operations). It sits at the top of the reasonable band without bloat or filler tools.

Completeness3/5

Create/read/edit/move are covered for folders, test cases, runs, and results, but delete operations are entirely absent (no deleteTestCase, deleteFolder, deleteTestRun, or result removal), leaving dead ends. Project handling is list-only and there is no single-resource get for a test case, so notable gaps remain.

Available Tools

15 tools

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

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

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

Name	Required	Description
`status`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare this is a write (readOnlyHint=false), non-idempotent, and non-destructive. The description adds a real behavioral constraint beyond them: the test case must already belong to the test run, i.e. the failure mode for an unprepared target. It says nothing about permissions, whether a duplicate comment is appended each call, or the rich-text format caveats that drive the 'format' parameter.

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 front-loaded sentence that carries the purpose and the precondition with no filler. It is tightly sized, though it is essentially the title plus one clause, so it does not demonstrate extra structure.

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 need no explanation, and the schema fully documents the five parameters. For a simple single-comment write, purpose plus the precondition is close to sufficient; only the behavior on repeated calls and permission needs are left implicit.

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, including the nuanced markdown/xml 'format' enum, is documented in the schema itself. The description adds no parameter-level meaning beyond that, so the 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 and resource ('Adds a comment to the result for a test case in a test run'), so an agent knows exactly what the tool creates and where it attaches. It does not differentiate itself from any sibling, but no sibling overlaps with commenting, so ambiguity risk is low.

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?

The description gives one precondition ('the test case must already be part of the test run'), which implies when the call will succeed, but says nothing about when to reach for this tool versus setTestResult or setTestResultBatch. Usage is inferable rather than explicit.

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

createFolderCreate a new test case folderBInspect

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

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

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

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, closed-world mutation, so the safety profile is covered. The description adds the nesting behavior, but does not disclose anything an agent couldn't infer from the annotations and schema, such as whether duplicate folder titles are allowed or what permissions are required.

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?

A single sentence that front-loads the action and resource and includes the one scoping nuance (optional nesting) without padding. Every clause earns its place.

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?

With an output schema present, return values need not be explained, and the 100%-covered schema plus annotations cover inputs and safety. The definition is nearly complete for a simple create tool; only the absence of usage/duplicate-handling guidance keeps it from a 5.

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 five parameters are already documented in the schema, including the parentFolder root-level behavior and the format semantics. The description adds no parameter detail beyond restating that nesting is optional, so the baseline of 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 specific verb+resource ('Creates a new test case folder') plus its scope ('in a project, optionally nested'), which clearly separates it from sibling tools like createTestCase or createTestRun. It stops short of naming a sibling alternative, but the resource is 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 when-to-use or when-not guidance. The description never tells the agent when to create a folder versus using createTestCase directly, nor does it reference editFolder/moveFolder as follow-ups (that hint only appears in the parentFolder schema description, not the tool description).

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

createTestCaseCreate a new test caseAInspect

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.

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), at most 48000 characters in all cells together. 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

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

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent create. The description adds genuinely new behavior: mismatched content is rejected with status 'content_does_not_match_template' rather than stored invisibly, and it warns that markdown edits to xml-bearing fields erase underline/color. It doesn't cover permissions or duplicate-title handling, so 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?

Purpose is front-loaded and the template explanation follows logically. Some content (template defaults, one-of rule) is restated near-verbatim from the schema descriptions, which is mild redundancy but not harmful.

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?

With an output schema present, return values need not be explained, and the description covers the main failure mode and content-model complexity for a 10-parameter nested tool. Minor gaps remain around custom field key resolution and authentication/prerequisites.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining the template/content mutual-exclusion rule and the markdown-vs-xml tradeoff for the 'format' parameter, which the schema only gestures at. It does not further clarify customFields keys or folder resolution beyond what the schema says.

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?

The opening sentence gives a specific verb and resource ('Creates a new test case in a given project') plus the scope of optional pieces. The rest distinguishes the three content templates (STEPS/TEXT/BDD), making it clearly separable from siblings like editTestCase.

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?

It states explicitly how to choose between templates and that content for exactly one must be supplied, with the rejection consequence spelled out. It does not say when to prefer this over a sibling such as editTestCase or how it relates to listProjects for custom field keys, so it falls short of full alternative routing.

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

createTestRunCreate a new test runAInspect

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

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

Name	Required	Description
`title`	Yes
`testRunId`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent creation. The description contributes the 'empty' initial-state detail, which is real added value. It says nothing about auth/permission needs, duplicate-title behavior, or whether the new run is returned with an ID — gaps that matter for a create tool.

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?

A single front-loaded sentence with no filler that conveys action, resource, and initial state. Nothing to trim and nothing buried.

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-value explanation is not needed, and with only two required, well-documented parameters the tool is simple. The description adequately covers the creation semantics; only permission/prerequisite context is absent.

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% and the format enum is explained at length in the schema itself, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond what the schema provides, making 3 the correct baseline.

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 and resource (create a test run) and adds the meaningful detail that the run starts empty, so an agent knows test cases and results are attached later. It does not differentiate itself from siblings like createTestCase or createFolder, but the resource nouns are distinct enough to avoid confusion.

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?

The phrase 'where test cases with results and comments can be added' implicitly positions this as the first step before setTestResult/addTestResultComment, which is useful workflow context. However there is no explicit when-to-use guidance, no mention of prerequisites (does the project need to exist?) and no named alternatives.

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

editFolderUpdate a test case folderA

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.

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

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.

editTestCaseEdit an existing test caseA

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.

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, at most 48000 characters in all cells together. 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

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

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the exact rejection status 'content_does_not_match_template' with the guarantee that nothing is written, the 'update_conflict' etag outcome, and that template switching preserves all templates' content. That is real failure-mode and side-effect disclosure the destructiveHint/idempotentHint flags cannot convey.

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 the partial-update contract, then organizes the rest by content type (STEPS / TEXT / BDD) before the template and etag rules - a sensible order for a complex tool. It is dense but has some duplication of schema-level facts ('empty string clears, omit keeps' appears three times), costing a little tightness.

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 an 11-parameter mutation tool with nested objects, the description covers the parts that actually trip agents up: template/content mismatch rejection, etag conflict flow, and the STEPS-index-after-switch pitfall. An output schema exists, so return values need not be explained, and the remaining field details live in the fully-described schema.

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

Parameters4/5

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

Schema coverage is 100%, so the per-field meanings are already covered, but the description adds cross-parameter semantics the schema cannot express: empty-string-clears vs omit-keeps as a global rule, the enforced coupling between 'template' and the content fields, and 0-based step indices referring to the pre-call list unaffected by same-call deletions.

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?

Opens with a precise verb+resource+scope: 'Partially updates an existing test case', and immediately clarifies the partial-update contract ('omitted fields are left as-is'), which implicitly separates it from createTestCase. It never names a sibling tool explicitly, so there is no direct routing statement, but the operation and its semantics 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?

Gives concrete use conditions rather than just a purpose: pass '_etag' when you want conflict detection, pass 'template' in the same call to write another template's content, and 'switch first, re-read, then edit the steps' for STEPS reversion. It does not compare against alternatives such as createTestCase or moveTestCases, so it stops short of full when-not guidance.

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

getTestStatusFetch test result information for test cases in a test runA

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

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

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

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds the useful detail of what data classes are returned (results, step results, comments, assignee), but says nothing about ordering, pagination, or limits on large runs.

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 front-loaded sentence with no filler, and the return-contents list is informative rather than redundant. It could be marginally tighter, but nothing wasted.

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?

With annotations covering the safety profile and an output schema documenting return values, the description only needs to establish scope and content, which it does. The one gap is behavior for large runs (ordering/pagination), which is a minor omission for a read tool.

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%, including a detailed format enum explanation and the effect of omitting testCaseId. The description adds no syntax or format meaning beyond what the schema already provides, so the baseline of 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 states a specific verb (gets) and resource (test case results, step results, comments, assignee) scoped to a test run, and clarifies it covers all test cases or one. It does not name or contrast any sibling such as setTestResult or listTestCases, so differentiation is left to the reader.

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?

The clause 'for all test cases or a specific one' implies the usage granularity, but there is no explicit when-to-use, when-not-to-use, or alternative named (e.g. setTestResult for writing results). Guidance is inferred rather than stated.

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

listProjectsList Testiny projectsA

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.

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

Output Schema

Name	Required	Description
`projects`	Yes

TDQS

A3.5/5.0

Behavior3/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 fully covered without description help. The description contributes some return-shape context about 'customFields' and its 'entity' values, but omits pagination, ordering, or completeness caveats.

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 core purpose is front-loaded in the first clause, and the following sentences are short and readable. The 'customFields' explanation is somewhat detailed relative to a single-parameter read tool, but it is not padded or repetitive.

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?

A low-complexity, single-optional-parameter read tool with an output schema, so return values need no further explanation. The description covers scope and output semantics adequately; only usage-vs-alternatives guidance is thin.

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% for the single optional 'keyword' parameter, so the schema already carries its meaning. The description does not reference 'keyword' at all, so it adds nothing beyond the structured field; 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+resource ('Retrieve a list of all accessible Testiny projects') and adds scope detail about the custom fields returned. It is inherently distinct from all siblings, which handle folders, test cases, runs, and results rather than projects, though no sibling is named.

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?

Provides a clear instruction on how to consume the output ('Filter by entity before using them'), which is genuine usage guidance. However, it says nothing about when to call this tool versus alternatives, prerequisites, or whether 'keyword' should be used for narrowing.

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

listTestCaseFoldersList Testiny test case foldersB

Read-onlyIdempotent

Inspect

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

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

Name	Required	Description
`testCaseFolders`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive and non-open-world, so the safety profile is fully covered structurally. The description adds essentially nothing behavioral beyond the schema's keyword parameter: no pagination or result-size behavior, no notice that it is scoped to a single project, no mention of the id-lookup shortcut for numeric keywords.

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 front-loaded sentence with zero wasted words and the filter caveat placed where it reads naturally. It is arguably too terse, but nothing in it is padding.

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 need no explanation, and annotations cover the safety profile. For a low-complexity, 3-parameter read tool this is close to complete; only the absence of any listing/scope caveats keeps it from full marks.

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 baseline is 3. The description restates the keyword filter with no added syntax, format or matching-semantics detail beyond what the schema already documents (including the 'TCF-'/'#' id-lookup rule).

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 (Retrieve) and resource (Testiny test case folders) plus its one notable modifier, an optional keyword filter. It does not explicitly distinguish itself from folder siblings like createFolder, editFolder or moveFolder, though the read-only listing intent is clear.

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?

'with an optional keyword filter' implies the search use case, and the tool name implies browsing folders in a project. There is no explicit statement of when this tool is preferred over listTestCases or the folder-mutation siblings, so usage is only implicitly conveyed.

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

listTestCasesList Testiny test casesC

Read-onlyIdempotent

Inspect

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

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
`testCases`	Yes

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.

listTestRunsList Testiny test runsB

Read-onlyIdempotent

Inspect

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

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

Name	Required	Description
`testRuns`	Yes

TDQS

B3.1/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 fully covered. The description adds nothing beyond that — no statement of result scope, pagination behavior, or whether all runs in the project are returned. It largely restates what the structured fields already convey.

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?

A single well-formed sentence with the core action front-loaded and no filler. Nothing in it is redundant or wasted.

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?

The output schema exists, so return values need not be explained, and the input schema covers all three parameters fully. However, for a list tool with no pagination or limit parameters, the description should say whether the result set is bounded or complete for the project — that scope question is left unanswered.

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 documents 'format', 'keyword', and 'project' including the id-lookup semantics and the markdown/xml trade-off. The description only repeats the keyword filter idea ('optional keyword filter') without adding format or project detail, so baseline 3 is correct.

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 and resource ('Retrieve a list of Testiny test runs') plus the scoping option ('optional keyword filter'). It is clearly distinguishable from write siblings like createTestRun and setTestResult, but it never names a list sibling (e.g. listTestCases) or clarifies why one would pick this over them.

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?

The only usage cue is that the filter is optional; there is no statement of when to use this versus listTestCases/listProjects, no prerequisite context, and no exclusion. The agent must infer the use case entirely.

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

moveFolderMove a test case folderA

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

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

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

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly=false, idempotent=true, destructive=false. The description adds genuinely new behavior beyond that: the circular-hierarchy validation rule and the fact that the move mutates '_etag' and returns the new value, which an agent needs for follow-up calls.

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?

Three tight sentences: purpose first, then the root special case, then the validation rule and return-value chaining. No filler, everything front-loaded.

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 the description needn't explain return shape, yet it still flags the _etag change needed for chaining to editFolder. Only minor gaps remain (no mention of permission requirements or what happens to the moved folder's contents), which is acceptable for a simple move.

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 (project, folderId, targetParentId) are already documented in the schema, including the '0 = root' convention. The description repeats the root hint without adding syntax or format detail beyond the schema, so 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 and resource: 'Moves a test case folder to a different parent folder.' The resource ('test case folder') inherently distinguishes it from the sibling moveTestCases, but the description never explicitly names or contrasts that sibling, so it stops short of a 5.

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 operational context (targetParentId=0 for root, circular moves rejected, chain the returned _etag into editFolder), but never states when to choose this tool over the near-identical moveTestCases sibling. Usage is implied rather than routed.

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

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.

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

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 runB

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

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

Name	Required	Description
`status`	Yes

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the description is not the sole carrier of the safety profile. It still adds real value beyond them by disclosing the upsert behavior: the test case is added to the run if it was not already part of it.

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?

One compact sentence with the core action front-loaded; no wasted preamble. It is slightly run-on because the upsert clause is appended, but nothing is redundant.

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?

With annotations covering safety and an output schema covering returns, the remaining gap is routing: nothing tells the agent when to prefer this over setTestResultBatch. Admissible but incomplete for a mutation tool with a close sibling.

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%, including detailed semantics for testResult and the notrun special case, so the schema carries the parameter burden. The description adds nothing about the parameters, which is the expected baseline when the schema is complete.

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 states a specific verb and resource: setting a test case result within a test run, plus the upsert side effect. It is clear on its own, but it never distinguishes itself from the sibling setTestResultBatch (single vs. bulk), which an agent must infer.

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 statement of when to use this tool versus setTestResultBatch or any other sibling, and no prerequisites or exclusions. Only implicit usage is conveyed by the phrasing.

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

setTestResultBatchSet the result for multiple test cases in a test runA

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

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

Name	Required	Description
`status`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), so the bar is lower, and the description adds a genuinely useful behavioral trait beyond them: test cases absent from the run are added as a side effect. It does not, however, say that existing results are overwritten or note permission requirements, leaving the destructive aspect implicit.

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 sentence that front-loads the primary action and appends the conditional side effect. It is efficient with no filler, though it is a fairly long compound sentence rather than crisply split.

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 need no explanation, and annotations cover the safety profile while the schema covers parameters. The remaining gap is routing guidance against setTestResult, which is the one thing an agent still has to infer.

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 67% and the schema already documents all three parameters in detail, including accepted result values and the 'notrun' semantics. The description adds no additional parameter meaning beyond what the schema provides, so the 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 (Sets the result) and resource (multiple test cases in a test run), and the 'multiple' scope distinguishes it from the singular sibling setTestResult without naming it explicitly. An agent can infer the batch nature, though the sibling is never named.

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?

Usage is only implied: the batch/multi-case framing suggests this is for bulk updates versus setTestResult. There is no explicit statement of when to prefer this over the single-result sibling, no prerequisites, and no exclusions.

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

Tool Schema Changelog

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

2 tool updatesOct 29, 2026

ChangedcreateTestCase1 field changed

changedInput schema / properties / steps / description

Previous 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."New value: +"The STEPS-template steps (interleaved action + expected result per step), at most 48000 characters in all cells together. Use this OR the TEXT 'text' content, not both. Omit if the test case has no steps."

ChangededitTestCase1 field changed

changedInput schema / properties / steps / description

Previous 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."New value: +"Partial updates for the STEPS-template steps, at most 48000 characters in all cells together. 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."

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
https://mcp.meistertask.com/mcp
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
https://mcp.cypress.io/mcp
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
https://api2.testrigor.com/api/v1/mcp
Orangescrum MCP ServerOAuth
com.orangescrum
Manage Orangescrum projects, tasks, users, sprints, test cases, releases, and risks from AI tools.
Project Management Testing & QA Tools
13
https://mcp.orangescrum.com/mcp/partner

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 a year ago (2025-12-01 14:22 UTC)
4
MIT
TestCollab MCP Server
Testing & QA Tools Developer Tools
TCSoftInc
A
license
A
quality
A
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 14 days ago (2026-10-19 09:19 UTC)
20
45 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
287 npm
1
MIT
Bugasura MCP Server
Testing & QA Tools Project Management Documentation Access
appachhi
A
license
Not graded
quality
C
maintenance
Connects AI assistants to test management workspaces through natural language, enabling management of test cases, issues, requirements, knowledge base documents, sprints, test runs, test data, and team collaboration.
Updated 3 days ago (2026-10-30 10:41 UTC)
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?