testit-mcp-server

update_project

DestructiveIdempotent

Replaces a project's full record by ID, clearing any fields not included in the request; use set_project for partial updates.

Instructions

Replace a project (PUT, full model with id); fields not sent are cleared. Prefer set_project.

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": {
      "payload": "<payload>"
    },
    "name": "update_project"
  }
}

Input Schema

Name	Required	Description	Default
`payload`	Yes

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 declare destructiveHint=true and idempotentHint=true, so the description's job is to explain why. 'Fields not sent are cleared' does exactly that, spelling out the destructive mechanism that the annotation only flags. It does not cover failure modes such as version conflicts or missing-id handling.

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?

Two tight clauses, destructive semantics front-loaded before the routing hint, with zero filler. Every phrase contributes information an agent needs before calling.

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 destructive full-replacement mutation with an opaque payload and no output schema, the description covers the essential risks: full replacement, silent clearing of omitted fields, id requirement, and a safer alternative. The remaining gap is that the payload model's fields are nowhere enumerated.

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?

The single payload parameter is an opaque nested object with 0% schema description coverage, so the description must carry the weight. 'Full model with id' is a genuinely useful constraint that the schema does not convey, but it never indicates which fields the model comprises.

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?

Names a specific verb ('Replace') and resource ('a project'), and pins down the semantics with 'PUT, full model with id'. It is distinguishable from set_project only via the routing hint rather than an explicit contrast, so it stops short of a 5.

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?

'Prefer set_project' gives an explicit alternative and a default, and 'PUT, full model with id' plus 'fields not sent are cleared' implies the condition under which this tool is the right choice. It never states that condition outright, so the agent must infer it.

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

Deploy Server