Skip to main content
Glama
testit-mcp-server

testit-mcp-server

by iampopovich

unlink_autotest_work_item

DestructiveIdempotent

Remove the link between an autotest and a work item by specifying their UUIDs, detaching the autotest from the associated test case.

Instructions

Remove the link between an autotest and a work item.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "workItemId": "<workItemId>"
    },
    "name": "unlink_autotest_work_item"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesAutotest UUID.
workItemIdYesWork item (test case) UUID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The phrase 'remove the link' does add the useful clarification that the autotest and work item entities themselves survive, only the association is deleted, but nothing is said about what happens if the link does not exist or what a successful response looks like.

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?

A single front-loaded sentence with zero filler; the operation and both entities appear immediately. It is efficient but so terse that it borders on under-specification rather than exemplary conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter unlink operation whose annotations already cover destructiveness and idempotency, the definition is adequate. It falls short of complete because it neither differentiates from the reversal/bulk siblings nor states the no-op behavior when the link 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%, with both UUIDs documented inline, so the schema carries the parameter burden. The description only implicitly maps 'autotest' to 'id' and 'work item' to 'workItemId', adding no format, constraint, or error semantics beyond the schema.

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?

The description uses a specific verb plus resource pair ('Remove the link between an autotest and a work item'), which is unambiguous about what is being unlinked versus deleted. It does not, however, distinguish itself from siblings such as 'unlink_work_item_autotests' (apparently a bulk or reversed variant) or 'link_autotest_work_item' (the inverse operation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this versus the inverse 'link_autotest_work_item' or the plural-looking 'unlink_work_item_autotests'. The use case is inferable from the verb, but no explicit context, prerequisites, or exclusions are stated.

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