Update a test plan by modifying only the fields you specify, without overwriting the rest. Pass the plan ID and a partial dictionary of values to apply changes directly.
Update a test plan with a partial field dict.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | ||
| plan_id | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses that the update is partial—only fields in the provided dict are changed—and that it is a mutation. However, it does not state permissions, whether the plan must exist, error behavior, or what response is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and resource; no filler or repetition. It earns its place by adding the 'partial field dict' semantics. Appropriate for the tool's small surface area.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, and the values schema is intentionally unconstrained, so the description should provide more operational context. Missing valid field names, example usage, or update semantics leave an agent guessing what to pass in values. As a mutation endpoint, it also omits response and error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'Partial field dict' tells the agent that values is a mapping of field names to update, which adds meaning to the open-values schema, but it does not enumerate valid test-plan fields or clarify plan_id beyond its name. The schema's types are left unexpanded.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the action ('Update') and the resource ('a test plan') clearly, and the 'partial field dict' qualifier distinguishes it from full create/replace operations. It is not merely restating the tool name; it adds the partial-update semantic. The 'test plan' resource scope also differentiates it from sibling update tools for cases, runs, and executions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to prefer this over create_test_plan, delete_test_plan, add_case_to_plan, or other mutation tools. The only usage cue is the verb 'Update', which is implied rather than explicit. There are no prerequisites, exclusions, or alternative-selection conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.