Skip to main content
Glama
testdino-hq

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update Manual Test Run

update_manual_run
Destructive

Modify an existing manual test run by sending only the fields to change, including closing it to freeze remaining cases. Use it to update run details or state without altering unrelated data.

Instructions

Modify an existing manual test run. Send only fields you want to change inside the updates object. Requires write permission. Allowed fields: name, note, environment, releaseId, state, forecast, tags, linkedIssues, links, selectionMode. Pass updates.status="closed" to close the run (same as the UI "Close run" button: freezes it, snapshots remaining cases, snaps state to the project's "Done" option). This is not reversible via MCP. Closed runs are read-only except for releaseId (so a run can be re-attached to a different release). Files cannot be added over MCP — tell the user to use the TestDino UI. IMPORTANT: updates.tags must be a JSON array of strings — e.g. ["smoke","regression"] — NOT a comma-separated string.

Input Schema

NameRequiredDescriptionDefault
runIdYesInternal _id or counter-style ID
updatesYesFields to update: name, note, environment, releaseId, state, forecast, tags, linkedIssues, links, selectionMode. status="closed" closes the run.
projectIdYesProject ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.3
    • changedInput schema / properties / updates / description
      Previous value: -"Fields to update: name, note, environment, releaseId, state, forecast, tags, linkedIssues, attachments, links, selectionMode. status=\"closed\" closes the run."New value: +"Fields to update: name, note, environment, releaseId, state, forecast, tags, linkedIssues, links, selectionMode. status=\"closed\" closes the run."
  2. Changed6 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 / projectId / description
      Previous value: -"Project ID (required)."New value: +"Project ID"
    • changedInput schema / properties / runId / description
      Previous value: -"Internal _id or counter-style ID (required)."New value: +"Internal _id or counter-style ID"
    • addedInput schema / properties / updates / additionalProperties
      Added value: +{}
    • changedInput schema / properties / updates / description
      Previous value: -"Fields to update: name, note, environment, releaseId, state, forecast, tags, linkedIssues, attachments, links, selectionMode."New value: +"Fields to update: name, note, environment, releaseId, state, forecast, tags, linkedIssues, attachments, links, selectionMode. status=\"closed\" closes the run."
  3. Addedv1.0.10

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag it as a destructive write; the description adds the real behavioral payload: write permission required, closing freezes the run and snapshots remaining cases, the action is irreversible via MCP, and closed runs are read-only except releaseId. That is exactly the context an agent needs before an unrecoverable mutation.

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?

Front-loaded with purpose and the partial-update rule, then layered constraints and the irreversibility warning. Every sentence carries operational information; the caps-lock tag warning is terse and load-bearing rather than decorative.

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 a destructive nested-object mutation with no output schema, the description covers permissions, reversibility, post-close mutation surface, unsupported operations, and the trickiest parameter format. Little is left for the agent to guess.

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

Parameters5/5

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

Schema coverage is already 100%, but the description goes well beyond it: it names the legal update fields (the schema leaves updates as additionalProperties with only a summary list), explains status="closed" semantics absent from the schema enum-free object, and warns that tags must be a JSON string array, not a comma-separated string - a real failure mode the schema does not catch.

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 and resource ("Modify an existing manual test run") and immediately scopes it to partial updates via the updates object, which distinguishes it cleanly from create_manual_run, get_manual_run, list_manual_runs and update_run_test_case.

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?

Clearly says to send only changed fields, explains when to use status="closed" versus a normal field update, and notes the UI alternative for file uploads. It stops short of naming sibling tools (e.g. update_run_test_case for per-case edits), so routing between close-adjacent mutations is left partly to inference.

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