testit-mcp-server

set_autotest

Idempotent

Partially update an autotest by changing only the supplied name, title, description, namespace, or classname fields; externalId remains uneditable as the result-matching key.

Instructions

Partially update an autotest (JSON Patch): only name, title, description, namespace, classname you pass change. externalId is the result-matching key and is not editable here.

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>"
    },
    "name": "set_autotest"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Autotest UUID.
`name`	No
`title`	No
`classname`	No
`namespace`	No
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 14, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=true), so the description's job is to add context, and it does: omitted fields are preserved (partial semantics) and externalId is flagged as the immutable result-matching key. It still says nothing about authorization requirements, error behavior on unknown fields, or what an update returns.

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?

Two sentences, front-loaded with the operation and immediately followed by the mutation rule and the one exclusion, with no filler. The phrase 'only name, title, description, namespace, classname you pass change' is grammatically awkward and could be tighter.

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 single-resource partial update with annotations present and no output schema, the description covers the essentials: what changes, what does not, and the immutability of the matching key. Minor gaps remain around value formats and failure modes, but nothing an agent needs to invoke it correctly is missing.

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?

Schema description coverage is only 17% (just 'id'), so the description must carry the optional parameters, and it does by enumerating exactly the five mutable fields that match the five optional properties. It adds the important semantics that unlisted fields are left unchanged and that externalId cannot be set, though it gives no format constraints for classname/namespace.

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 ('Partially update an autotest') and pins down that only the five named fields are mutated, which separates it from create_autotest/delete_autotest without needing to name them. The '(JSON Patch)' parenthetical is slightly misleading because the schema is a flat field map, not RFC 6902 operations, which introduces a small ambiguity about what the caller should send.

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?

The word 'partially' plus 'only ... you pass change' gives clear context for when to reach for this over a full overwrite, and 'externalId ... is not editable here' is an explicit when-not. It stops short of naming a sibling to use instead for matching-key changes, so it is clear context with one exclusion rather than full alternative routing.

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

Deploy Server