testit-mcp-server

set_work_item

Idempotent

Partially update a TestIT work item by changing only specified fields and creating a new version; use it for name, tags, state, priority, or description edits. Move items between sections separately.

Instructions

Partially update a work item: only the given fields change (JSON Patch), each call creates a new version. Prefer this over update_work_item (full replacement). Use move_work_item to change section.

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_work_item"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Work item UUID.
`name`	No
`tags`	No	Tag names; replaces all tags.
`state`	No
`priority`	No
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 14, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond the annotations it discloses two behaviors the agent could not infer: that this is a true partial patch, and that every call creates a new version — a side effect worth knowing before looping. It does not mention permission requirements or what the response contains, and the per-call versioning sits in mild tension with idempotentHint=true, though the resulting resource state is still idempotent, so no contradiction is claimed.

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?

Three short clauses, each carrying a distinct fact: partial-update semantics, version creation, and two sibling disambiguations. The most decision-relevant information (partial vs. full replacement) is front-loaded with zero filler.

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 six-parameter mutation tool with no output schema, the description covers mechanism, side effects, and alternatives well. What is missing is modest: no note on required permissions/scope or on what a successful call returns (e.g., the new version identifier), which would matter for an agent that intends to chain calls.

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 only 33%, with name, state, priority, and description undocumented in the schema. The description partially compensates by establishing that omitted fields are left untouched, which is the key semantic for all six parameters, but it adds no detail on the enumerations or on how null/empty values are treated for non-tag fields.

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 ("Partially update a work item") plus the defining mechanism (JSON Patch, only given fields change). It explicitly separates itself from update_work_item (full replacement) and move_work_item (section changes), so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit preference rule ("Prefer this over update_work_item") and names the tool to use for the adjacent case ("Use move_work_item to change section"). Both the when and the when-not are covered with named alternatives.

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

Deploy Server