Testiny Test Management

Create a new test run

createTestRun

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

Input Schema

Name	Required	Description
`title`	Yes	The title of the test run (e.g. "Regression test release v1.2.3", "Feature test XYZ")
`format`	No	Format for rich-text fields (descriptions, preconditions, comments, step & result cells, stepsText & expectedResultText) on both input and output: 'markdown' (default) or 'xml'. Read the matching rich-text format reference resource before producing either. Use 'xml' for BOTH the read and the write whenever you are changing a field that already has content: markdown cannot carry an underline or a text color, so an edit written as markdown writes those away. 'markdown' is for writing new content and for reading you will not edit.
`project`	Yes	Project ID (number or string), project key or part of the project name
`description`	No	An optional description of the test run - rich text in the chosen 'format'

Output Schema

Name	Required	Description	Default
`title`	Yes
`testRunId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 12, 2026

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

First observedOct 2, 2026

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.

All Testiny Test Management tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?