Create a structured test plan by specifying name, description text, product, version, and type. Optionally set a parent plan or extra link to organize your testing workflow.
Create a test plan. values needs: name, text, product_id (or product), product_version_id (or product_version), type_id (or type). Optional: parent_id, is_active, extra_link.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create' implies a persistent write, but the description discloses no side effects, permissions required, reversibility, or what a successful call returns. For a mutation tool with zero annotation coverage, this is a significant transparency gap.
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?
Two tight sentences: the purpose is front-loaded, and the field specification is compactly formatted into required and optional groups. Every sentence earns its place with zero filler or redundancy.
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 description equips an agent to construct the `values` payload with required vs optional keys and aliases, which is the critical calling surface for this free-form nested object. However, it omits field value types (e.g., boolean for is_active, URL format for extra_link), any return-value description (no output schema exists), and pointers to sibling lookup tools for resolving product_id/type_id, leaving the request understandable but not fully grounded.
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?
The schema provides 0% coverage — `values` is a free-form object with additionalProperties and no nested documentation — so the description fully compensates. It enumerates required fields (name, text, product_id/product, product_version_id/product_version, type_id/type), optional fields (parent_id, is_active, extra_link), and documents aliases for each ID. This is exactly the semantic value the schema fails to provide.
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?
'Create a test plan' is a specific verb+resource statement that immediately distinguishes this from sibling mutations like kiwi_update_test_plan, kiwi_create_test_case, and kiwi_create_test_run. The field detail on `values` further scopes it to plan-specific attributes (product_id, type_id, parent_id), making its purpose unmistakable.
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 is given on when to use this tool versus alternatives such as kiwi_update_test_plan (for modifying existing plans) or kiwi_create_test_case. There are no exclusions, prerequisites, or pointers to companion lookup tools like kiwi_get_products or kiwi_get_plan_types for sourcing required IDs — the required-field list only weakly implies preparation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.