Skip to main content
Glama

Testiny Test Management

Create a new test case

createTestCase

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.

Input Schema

NameRequiredDescriptionDefault
textNoContent 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.
stepsNoThe 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.
titleYesThe title of the test case, descriptive but not too long
folderNoThe 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.
formatNoFormat 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.
projectYesProject ID (number or string), project key or part of the project name
templateNoWhich 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.
bddScenariosNoContent 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.
customFieldsNoCustom 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.
preconditionNoAn optional precondition for the test case - rich text in the chosen 'format'

Output Schema

NameRequiredDescriptionDefault
_etagNoConflict 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.
statusYes
testCaseIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema 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."
  2. Changed14 schema 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"
      +}
  3. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources