TestDino MCP

Create Release

create_release

Create a new release in TestDino, set its project, dates, build target, branch, environment, and testers, and nest it under a parent release.

Instructions

Create a new release. Requires write permission. Use parentReleaseId to nest under another release (max 3 levels deep). startDate/endDate are ISO date strings. isStarted/isCompleted are independent flags — startedAt/completedAt are recorded separately. branch/environment/buildTarget/testers describe what build the release ships and who tests it (testers must be org members — pass User _ids).

Input Schema

Name	Required	Description
`name`	Yes	Release name
`note`	No	Rich HTML note
`type`	No	Release type. Default options: "release", "version", "sprint", "iteration", "plan", "cycle", "feature" (case-insensitive — server lowercases on save so the UI badge color matches). Projects can add or rename types via Project Settings → Release Types; pass the value the project actually has.
`branch`	No	Source branch this release ships from.
`endDate`	No	ISO date
`testers`	No	User _ids assigned as testers. Must be members of the org.
`isStarted`	No
`projectId`	Yes	Project ID
`startDate`	No	ISO date
`startedAt`	No	ISO datetime
`buildTarget`	No	Build the release cuts against: { platform: "web"\|"ios"\|"android"\|"api", version, buildNumber, source, deployUrl }. An all-empty object is stored as null.
`completedAt`	No	ISO datetime
`description`	No
`environment`	No	Environment label this release targets, e.g. "Staging".
`isCompleted`	No
`linkedIssues`	No	Array of linked-issue objects (same shape as list_releases returns).
`parentReleaseId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed28 schema fields changedv2.2.0Oct 14, 2026

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / branch / description

Previous value: -"Source branch this release ships from"New value: +"Source branch this release ships from."

addedInput schema / properties / buildTarget / additionalProperties
```
Added value: +true
```

changedInput schema / properties / buildTarget / description

Previous value: -"Build target details."New value: +"Build the release cuts against: { platform: \"web\"|\"ios\"|\"android\"|\"api\", version, buildNumber, source, deployUrl }. An all-empty object is stored as null."

removedInput schema / properties / buildTarget / properties / buildNumber / description
```
Removed value: -"Build number."
```
removedInput schema / properties / buildTarget / properties / deployUrl / description
```
Removed value: -"Deployment URL."
```

addedInput schema / properties / buildTarget / properties / platform / anyOf

Added value: +[
+  {
+    "enum": [
+      "web",
+      "ios",
+      "android",
+      "api"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / buildTarget / properties / platform / description
```
Removed value: -"Build platform."
```
removedInput schema / properties / buildTarget / properties / platform / enum
```
Removed value: -[
-  "web",
-  "ios",
-  "android",
-  "api"
-]
```
removedInput schema / properties / buildTarget / properties / platform / type
```
Removed value: -"string"
```
removedInput schema / properties / buildTarget / properties / source / description
```
Removed value: -"Build source."
```
removedInput schema / properties / buildTarget / properties / version / description
```
Removed value: -"Build version."
```

changedInput schema / properties / completedAt / description

Previous value: -"ISO datetime."New value: +"ISO datetime"

changedInput schema / properties / endDate / description
```
Previous value: -"ISO date."New value: +"ISO date"
```

changedInput schema / properties / environment / description

Previous value: -"Environment label, e.g. 'Staging'"New value: +"Environment label this release targets, e.g. \"Staging\"."

changedInput schema / properties / linkedIssues / description

Previous value: -"Array of linked-issue objects (same shape list_releases returns)."New value: +"Array of linked-issue objects (same shape as list_releases returns)."

addedInput schema / properties / linkedIssues / items / additionalProperties
```
Added value: +true
```

addedInput schema / properties / linkedIssues / items / properties

Added value: +{
+  "displayId": {
+    "type": "string"
+  },
+  "issueType": {
+    "type": "string"
+  },
+  "source": {
+    "type": "string"
+  },
+  "status": {
+    "type": "string"
+  },
+  "title": {
+    "type": "string"
+  },
+  "url": {
+    "type": "string"
+  }
+}

addedInput schema / properties / linkedIssues / items / type
```
Added value: +"object"
```

changedInput schema / properties / name / description

Previous value: -"Release name (required)."New value: +"Release name"

changedInput schema / properties / note / description

Previous value: -"Rich HTML note."New value: +"Rich HTML note"

removedInput schema / properties / parentReleaseId / description
```
Removed value: -"Parent release for nesting."
```

changedInput schema / properties / projectId / description

Previous value: -"Project ID (required)."New value: +"Project ID"

changedInput schema / properties / startDate / description
```
Previous value: -"ISO date."New value: +"ISO date"
```

changedInput schema / properties / startedAt / description

Previous value: -"ISO datetime."New value: +"ISO datetime"

changedInput schema / properties / testers / description

Previous value: -"User _ids assigned as testers; must be org members"New value: +"User _ids assigned as testers. Must be members of the org."

changedInput schema / properties / type / description

Previous value: -"Release type. Either canonical ('iteration', 'major') or display ('Iteration', 'Major') form — server normalizes to lowercase so UI badge color matches."New value: +"Release type. Default options: \"release\", \"version\", \"sprint\", \"iteration\", \"plan\", \"cycle\", \"feature\" (case-insensitive — server lowercases on save so the UI badge color matches). Projects can add or rename types via Project Settings → Release Types; pass the value the project actually has."

Changed4 schema fields changedv2.0.2Aug 12, 2026

addedInput schema / properties / branch

Added value: +{
+  "description": "Source branch this release ships from",
+  "type": "string"
+}

addedInput schema / properties / buildTarget

Added value: +{
+  "description": "Build target details.",
+  "properties": {
+    "buildNumber": {
+      "description": "Build number.",
+      "type": "string"
+    },
+    "deployUrl": {
+      "description": "Deployment URL.",
+      "type": "string"
+    },
+    "platform": {
+      "description": "Build platform.",
+      "enum": [
+        "web",
+        "ios",
+        "android",
+        "api"
+      ],
+      "type": "string"
+    },
+    "source": {
+      "description": "Build source.",
+      "type": "string"
+    },
+    "version": {
+      "description": "Build version.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / environment

Added value: +{
+  "description": "Environment label, e.g. 'Staging'",
+  "type": "string"
+}

addedInput schema / properties / testers

Added value: +{
+  "description": "User _ids assigned as testers; must be org members",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Addedv1.0.10May 19, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations only tell the agent this is a non-read-only, non-destructive write; the description adds substantive behavior beyond that: write permission is required, nesting is capped at 3 levels, isStarted/isCompleted are independent of startedAt/completedAt, and testers must be org members passed as User _ids. It does not describe the returned resource or any conflict/failure behavior, keeping it out of the top band.

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 core action and permission requirement, then groups the remaining guidance in a compact set of sentences where each clause carries a distinct constraint. The final sentence is slightly run-on, but no sentence is filler.

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?

For a 17-parameter mutation tool with nested objects and no output schema, the description covers the non-obvious fields (nesting depth, flags vs timestamps, tester identity rules) while the schema handles the rest at 76% coverage. Return-shape and failure behavior are absent, but the agent has enough to invoke it correctly.

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?

With 76% schema coverage the schema already documents most fields, yet the description adds genuine semantics: the 3-level nesting limit for parentReleaseId, the independence of isStarted/isCompleted from the timestamp fields, the ISO format for startDate/endDate, and the org-membership plus User _id requirement for testers. It leaves the type, note, linkedIssues and buildTarget sub-fields to the schema, so it does not fully compensate but adds clear value.

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 new release"), which distinguishes it clearly from the read/update siblings list_releases, get_release and update_release. It stops short of explicitly naming an alternative, but the verb+resource pairing 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 Guidelines3/5

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

Provides real prerequisites ("Requires write permission") and a structural constraint (nesting via parentReleaseId, max 3 levels), which implies when the tool applies. It never says when to use this versus update_release or what conditions would make creation inappropriate, so guidance is present but incomplete.

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

Deploy Server

Create Release

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools