Skip to main content
Glama
testdino-hq

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Quarantine Tests

quarantine_tests
Destructive

Quarantine up to 100 tests until a set end date so their failures stop failing the build while tests still run and are reported; include a reason and optionally preview with dry run.

Instructions

Call this only when the user asks for it. Quarantine 1 to 100 tests: until the end date, their failures stop failing the build (they still run and are reported). reason is required and becomes the quarantine note. ends_in_days defaults to the project's default length. assignee defaults to the test's assignee for one test, else to you; the assignee also starts watching the test and is notified when it changes state. only_this_error (one test only) takes an error line and covers only failures with that error; other failures still fail the build. Pass the error of the test's final attempt, the one the build is judged on. dry_run: true creates nothing and reports what would be quarantined, what would be skipped and why, and the quarantine limit — use it before a large quarantine. It does not check only_this_error or that the assignee is a project member; the real call does. Several tests are all-or-nothing against the limit; already quarantined tests are skipped. A quarantine cannot be deleted, only released.

Input Schema

NameRequiredDescriptionDefault
reasonYesWhy these tests are quarantined
dry_runNo
assigneeNo"me", a user id or a teammate's email
projectIdYesProject ID (e.g. project_<id>)
ends_in_daysNo
testcase_idsYesPlaywright pw_test_ids, as list_testcase returns them
only_this_errorNoThe error line to cover, from the test's final attempt; one test only

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.3
    • changedInput schema / properties / only_this_error / description
      Previous value: -"The error line to cover; one test only"New value: +"The error line to cover, from the test's final attempt; one test only"
  2. Addedv2.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the annotations: it discloses the all-or-nothing limit behavior, that already-quarantined tests are skipped, that assignees start watching and get notified, that dry_run creates nothing and reports skips/limits but omits some real-call checks, and critically that "a quarantine cannot be deleted, only released." That last point is essential behavioral context for a destructiveHint=true tool.

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?

The action and its effect are front-loaded and every sentence carries information, but the middle section is a dense run of semicolon-linked clauses that takes effort to parse. Slightly tighter grouping of the parameter semantics would improve scanability.

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 7-parameter, non-read-only mutation with no output schema, the description covers the mutation's effect, defaults, limits, skip behavior, dry_run output, and irreversibility. Nothing an agent needs to call it correctly is missing.

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?

With 71% schema coverage, the description fills the remaining gaps and adds real semantics: reason becomes the quarantine note, ends_in_days falls back to a project default, assignee has tiered defaults (test's assignee for one test, else the caller) plus a watch/notify side effect, and only_this_error is scoped to one test and to the final attempt's error. These are behavioral meanings the schema cannot express.

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 with explicit scope: "Quarantine 1 to 100 tests" and spells out the effect ("their failures stop failing the build (they still run and are reported)"). An agent can distinguish this from update_quarantine or release_quarantine purely from the description.

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 hard usage gate ("Call this only when the user asks for it") and conditions for dry_run ("use it before a large quarantine") and only_this_error (one test only, final attempt error). It does not explicitly name sibling alternatives such as update_quarantine or release_quarantine, so it stops short of full routing guidance.

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