Skip to main content
Glama
testdino-hq

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create External Issue

create_external_issue

Create Jira, Linear, Asana, or monday.com issues from TestDino test runs, cases, suites, releases, or sessions. Check get_integration_status first for required fields.

Instructions

Create a provider issue/task/item linked to a TestDino entity. Supported source types include automated and manual runs, test cases, suites, releases, and sessions. Check get_integration_status first for required provider fields.

Input Schema

NameRequiredDescriptionDefault
sourceYesTestDino entity to link with the external issue.
targetNoProvider-specific target/field values. Jira accepts human-readable aliases such as { jiraProjectKey: "TRX", issueType: "Bug" } or { jiraProjectName, issueTypeName }; raw { jiraProjectId, issueTypeId } also works. Linear { teamId }, Asana { workspaceId, projectId }, monday.com { boardId }.
previewNoWhen true, resolve and return the issue draft without creating anything in the provider.
summaryNoIssue title. Later phases can derive this from source.
linkBackNoWhether TestDino should link the created external issue back to the source entity.
providerYesProvider to create the issue in. GitHub can be connected but not written to.
projectIdYesTestDino project ID
descriptionNoIssue body/description. Later phases can derive this from source.
idempotencyKeyNoCaller-provided stable key for retrying the same create request without creating duplicates when supported downstream.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv2.2.0
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / description / description
      Previous value: -"Issue description body. Supports plain text."New value: +"Issue body/description. Later phases can derive this from source."
    • changedInput schema / properties / idempotencyKey / description
      Previous value: -"Unique key to prevent duplicate issues on retry. Use a stable identifier such as the source entity ID."New value: +"Caller-provided stable key for retrying the same create request without creating duplicates when supported downstream."
    • changedInput schema / properties / linkBack / description
      Previous value: -"When true, the created issue is linked back to the TestDino source entity (currently supported for Jira)."New value: +"Whether TestDino should link the created external issue back to the source entity."
    • changedInput schema / properties / preview / description
      Previous value: -"When true, returns the draft that would be created (wouldCreate: false) without filing the issue."New value: +"When true, resolve and return the issue draft without creating anything in the provider."
    • changedInput schema / properties / projectId / description
      Previous value: -"Project ID (Required). The TestDino project identifier."New value: +"TestDino project ID"
    • changedInput schema / properties / provider / description
      Previous value: -"Integration provider to file the issue in (Required)."New value: +"Provider to create the issue in. GitHub can be connected but not written to."
    • changedInput schema / properties / provider / enum
      Previous value: -[
-  "jira",
-  "linear",
-  "asana",
-  "monday",
-  "github"
-]New value: +[
+  "jira",
+  "linear",
+  "asana",
+  "monday"
+]
    • addedInput schema / properties / source / additionalProperties
      Added value: +false
    • changedInput schema / properties / source / description
      Previous value: -"TestDino source entity the issue is about (Required). Both fields are required."New value: +"TestDino entity to link with the external issue."
    • changedInput schema / properties / source / properties / id / description
      Previous value: -"Source entity ID, counter-style ID, or key within TestDino."New value: +"TestDino entity ID, counter-style ID, or key."
    • addedInput schema / properties / source / properties / id / minLength
      Added value: +1
    • changedInput schema / properties / source / properties / type / description
      Previous value: -"Source entity type. Use manual_test_case / manual_run / session for TCM entities and test_case / test_run / test_suite for automated ones."New value: +"TestDino entity type the external issue should be associated with."
    • changedInput schema / properties / source / properties / type / enum
      Previous value: -[
-  "test_case",
-  "test_run",
-  "test_suite",
-  "manual_test_case",
-  "manual_test_suite",
-  "release",
-  "manual_run",
-  "manual_run_test_case",
-  "session"
-]New value: +[
+  "test_run",
+  "test_suite",
+  "test_case",
+  "manual_test_case",
+  "manual_test_suite",
+  "release",
+  "manual_run",
+  "manual_run_test_case",
+  "session"
+]
    • changedInput schema / properties / summary / description
      Previous value: -"Issue title/summary. Optional — derived from the source entity when omitted."New value: +"Issue title. Later phases can derive this from source."
    • changedInput schema / properties / target / additionalProperties
      Previous value: -trueNew value: +{}
    • changedInput schema / properties / target / description
      Previous value: -"Provider-specific destination fields (e.g. Jira project key and issue type, monday board ID). Discover available fields via get_integration_status with includeCreateOptions: true."New value: +"Provider-specific target/field values. Jira accepts human-readable aliases such as { jiraProjectKey: \"TRX\", issueType: \"Bug\" } or { jiraProjectName, issueTypeName }; raw { jiraProjectId, issueTypeId } also works. Linear { teamId }, Asana { workspaceId, projectId }, monday.com { boardId }."
  2. Addedv2.0.2

TDQS

A3.6/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the agent already knows this is a non-destructive write; the description adds useful context that a preview mode exists and that provider field requirements should be verified first. It does not, however, state auth needs, what happens on partial failure, or how duplicate creation is prevented beyond what the schema says.

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?

Three short sentences, front-loaded with the core action and followed by scope and a prerequisite. Zero padding, though the source-type list is partially redundant with the schema enum.

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 9-parameter, nested-object create tool with no output schema and modest annotations, the description covers the action, scope, and the key prerequisite well. The schema carries the heavy lifting on parameters and the preview flag, leaving only return-shape/error details unaddressed.

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 every parameter is already documented in the input schema, including the rich 'target' description with provider-specific aliases. The description's enumeration of source types largely restates the schema's enum, so it adds little beyond the structured fields; baseline 3 is appropriate.

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 (Create) and resource (external issue/task/item) and pins its scope with 'linked to a TestDino entity'. It enumerates the supported source types, which helps distinguish it from the sibling get_external_issue. It stops short of explicitly naming that sibling as its read counterpart, so it lands at 4 rather than 5.

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 a concrete prerequisite: 'Check get_integration_status first for required provider fields,' naming the sibling and the condition that routes to it. It does not describe when NOT to use this tool (e.g., when only reading existing issues), but the positive usage guidance is explicit.

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

Deploy Server

Other Tools