kiwi-tcms-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.2
Disambiguation5/5
Each tool clearly targets a specific resource and action (e.g., creating runs, adding cases, listing executions, managing attachments). Even similar-sounding tools like kiwi_list_executions and kiwi_run_get_cases have distinct purposes (filtering vs. retrieving run cases).
Naming Consistency4/5
Tool names consistently use the kiwi_ prefix and snake_case, but the verb/noun order varies (kiwi_create_run vs. kiwi_run_add_case). This minor inconsistency is readable and does not cause confusion.
Tool Count2/5
68 tools is well beyond the recommended range and may overwhelm agents. The server covers a large domain, but many operations could be consolidated (e.g., generic attachment/property tools already exist).
Completeness5/5
The surface covers nearly every Kiwi TCMS workflow: full CRUD for cases/plans/runs, execution management, tags, attachments, properties, links, and a generic RPC fallback. No obvious dead ends remain.
Average 3.3/5 across 68 of 68 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on August 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions 'component name' and gives no information about side effects, whether the component must already exist, overwrite behavior, or return values. The mutation behavior is not disclosed at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concisely useful. It is a fragment that does not earn its place because it repeats the title and adds only the parameter name, which is already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is incomplete: it omits return value expectations, prerequisites, and relationship to sibling component tools. The agent cannot fully assess what the tool will do or when to invoke it.
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 100% with both parameters described ('Test case id' and 'Component name'). The description adds no extra semantic meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'TestCase.add_component: component name.' essentially restates the tool name and title without explaining what adding a component does or what a component is. It does not distinguish from sibling tools like kiwi_case_remove_component beyond the verb, which the title already conveys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as kiwi_case_add_tag or kiwi_case_remove_component, nor any prerequisites like the component needing to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint: false. The description adds a note about classification defaulting to the first classification, but does not disclose other behavioral aspects such as whether name must be unique, permissions required, or what happens on creation. The operation's side effects are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not effectively concise. 'Product.create' is cryptic filler, and the classification sentence duplicates what the schema already provides. The description feels under-specified rather than intentionally compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three parameters, a complete description should at least state that it creates a project. Here the core purpose is missing, and with no output schema and minimal annotations, the description leaves the agent without sufficient information to understand the tool's role.
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 100%, so all three parameters already have meaningful descriptions. The description repeats the classification default from the schema without adding additional meaning, so it stays at the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Product.create' is a vague label that does not explicitly state the tool creates a project. The title provides clarity, but the description itself lacks a clear verb+resource statement and could even imply product creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling create tools like kiwi_create_plan, kiwi_create_run, or kiwi_create_case. There are no exclusions, prerequisites, or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already tells the agent this is a safe read operation. The description adds little: it mentions 'catalog required by Product.create', which could hint at a required filter context, but it doesn't clarify what the tool actually does or what happens when used without a catalog. There is no contradiction, but the behavioral context is minimal and confusing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence, which is brief, but it's not effectively concise because the sentence is opaque and fails to communicate the tool's purpose. It reads more like a developer note than a user-facing description, making it under-specified rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with read-only annotation and two documented params, the description should quickly clarify what classifications are, why 'catalog' matters, and how this fits with Product.create. Instead, it leaves these questions unanswered, so the tool's context is incomplete despite the rich schema and sibling context.
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 input schema provides full descriptions for both parameters (limit and query), so the schema alone is sufficient. The description does not add any parameter-level information beyond what's in the schema. Baseline of 3 is appropriate since coverage is 100% and the description doesn't mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and name clearly say 'List classifications', but the description itself is cryptic: 'Classification.filter: catalog required by Product.create.' It doesn't explicitly state that the tool lists classifications or what the returned data represents. The phrase 'Classification.filter' suggests filtering, but the purpose is muddled and not clearly tied to the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many other list_* tools. The mention of 'catalog required by Product.create' implies a use case, but it's unclear whether the tool requires a catalog parameter (it does not have one) and how it relates to product creation. No comparison to alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and safety. The phrase "as the logged-in user" hints that the comment is attributed to the current user, which is a behavioral trait, but it does not mention whether the comment is permanent, whether write permissions are needed, or what feedback is returned. This is minimal transparency for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (a single sentence), which is concise, but it is not well-structured for an agent. It starts with a code method name "TestCase.add_comment" rather than a plain-language verb phrase, and it omits key explanatory context. Every word is minimal but not sufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description still needs to explain the action's effect and any relevant context. It only provides a code reference and an auth note; it does not state that a comment is appended to a case, what the expected outcome is, or how it relates to case history. The description is incomplete for safe and correct invocation.
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 input schema already provides full documentation for both parameters (id as "Test case id" and comment as "Comment text"), so the schema description coverage is 100%. The description adds no additional parameter semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title "Add comment to test case" clearly states the action and resource, and the description's "TestCase.add_comment" aligns with that intent. However, the description itself is a code method reference rather than a plain-language explanation, which may confuse agents unfamiliar with the Kiwi TCMS API. It does not explicitly say "Adds a comment to a test case," so the purpose is only implicitly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative actions like adding tags or components, nor any mention of prerequisites. The only hint is "as the logged-in user," which implies authentication but does not explain when commenting is appropriate. This dimension is essentially unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It merely states the operation and a filter, but does not mention that removal is destructive, whether it requires permissions, what happens if multiple properties match, or if the operation is reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, but the first clause 'TestCase.remove_property' largely repeats the tool name and title, adding no new information. The second clause provides some filter guidance, but the overall structure could be improved by eliminating redundancy and including essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is incomplete. It fails to mention property_id, does not clarify how the filtering works when multiple properties exist, and does not describe what the tool returns or any side effects. The schema covers parameter names but not usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, but the description adds 'Filter by case_id and/or name,' which omits property_id and could mislead an agent into thinking only those two parameters are relevant. This introduces ambiguity rather than adding clear semantic value beyond the schema.
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?
The title and description clearly indicate this tool removes a property from a test case. The phrase 'TestCase.remove_property' and 'Filter by case_id and/or name' give a clear sense of the operation, but the description omits the property_id parameter, which is part of the schema and could be the primary removal key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like kiwi_case_add_property or removal tools for tags/components. The only hint is 'Filter by case_id and/or name,' which suggests some selection logic but does not explain prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the readOnlyHint annotation indicates a safe read operation, the description adds no additional behavioral context. It does not mention pagination, ordering, return format, or any side effects beyond the cryptic filter note, so it provides little transparency value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but underspecified. It is a single fragmented phrase ('PlanType.filter: Functional, Acceptance, etc.') that sacrifices clarity for brevity, making it ineffective as a guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns or how it behaves. It does not state that the tool returns a list of plan types or provide any usage context. The simple tool could benefit from a one-sentence clarification such as 'Returns all plan types, optionally filtered by name substring.'
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 100%, so the parameters (limit and query) are fully documented in the schema. The description adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'PlanType.filter: Functional, Acceptance, etc.' is vague and does not clearly state the tool's action or resource. It reads more like a cryptic shorthand than a purpose statement, though the title 'List plan types' provides some clarity. It does not meaningfully distinguish from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_classifications or create_plan_type. No use cases, prerequisities, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of disclosing behavior. It only shows the method name and an example value; it does not state that this is a write operation, require any permissions, or explain the effect on plan/case ordering. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It is a fragment rather than a proper explanatory sentence. It leaves out essential context, so brevity here is not effective conciseness but rather omission.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (3 required scalar params, no output schema), the description is incomplete for safe invocation. It does not articulate the operation's purpose, distinguish from sibling plan tools, or provide any behavioral context. The agent must rely on the title and schema, which is insufficient.
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 100%, with sortkey already described as 'Display order in the plan, e.g. 10, 20, 30'. The description repeats the sortkey example but adds no new parameter meaning. Given high schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a code reference 'TestPlan.update_case_order: sortkey, e.g. 10, 20, 30.' which names the method and gives an example sortkey but does not explicitly explain the tool's purpose. The title 'Update case order in plan' is clearer, but the description itself lacks a verb+resource statement, making it vague for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool compared to alternatives like kiwi_plan_add_case or kiwi_plan_remove_case. The description only provides a sortkey example and does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It only hints at setting is_defect to mark a defect, but does not mention mutation, permissions, potential side effects (e.g., update_tracker), or return behavior. This is minimal disclosure for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, but it includes redundant text ('TestExecution.add_link' repeats the tool name/title) and is not well-structured. The useful part is the is_defect hint, but the format is cryptic and could be more front-loaded with a clear statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and no output schema, the description is inadequate. It does not explain typical usage scenarios (e.g., attaching a bug tracker URL), how update_tracker works, or what the response looks like. The keyword list is not enough to fully understand the tool's role.
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 100% with descriptive comments for all parameters. The description's is_defect hint ('Set is_defect to mark a defect.') merely restates the schema's 'Mark this link as a defect'. No additional parameter semantics are provided, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Add execution link' makes the purpose clear, and the description adds context keywords (bug, Allure, CI). However, the description itself is a fragment ('TestExecution.add_link: bug, Allure, CI.') and does not explicitly state that it adds a link to an execution, relying on the tool name and title for the primary meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It mentions use cases like bug, Allure, and CI, but does not state exclusions or name sibling tools (e.g., kiwi_execution_remove_link for removal). The agent is left to infer intent from the 'add_link' name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds minimal context by naming the underlying filter method and giving example values, but it does not disclose pagination behavior, ordering, or whether all statuses are returned by default. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but is not a well-formed sentence; it reads as a code comment or method signature. While there is no wasted text, the lack of a proper sentence structure and clear subject/predicate means it is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of many sibling list tools, the description should provide context about the domain (test case statuses) and the kinds of values returned. It only offers examples and a method name, leaving the agent to guess the tool's full functionality. A simple list tool could be fully described in one or two sentences, but this description is incomplete.
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 input schema fully documents both parameters (limit and query) with clear descriptions, so the description does not need to repeat them. The mention of 'TestCaseStatus.filter' does not add semantic detail about parameter behavior beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'TestCaseStatus.filter: CONFIRMED, PROPOSED, DISABLED…' is a fragment that references the underlying RPC method and provides examples of statuses, but it does not explicitly state that the tool lists test case statuses. The title does clarify the purpose, but the description itself is vague and does not differentiate it from sibling lists such as kiwi_list_execution_statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of other list tools. There are no alternatives mentioned, no context about when statuses are needed, and no exclusions. The description and annotations are silent on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. However, it merely restates the function name and lists the input fields ('filename plus base64 content'), without mentioning side effects, permissions, file size limits, or error conditions. This is a significant transparency gap for a mutation tool.
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?
The description is extremely concise at one sentence, with no filler words. However, the first part 'TestCase.add_attachment' simply echoes the tool name, which is somewhat redundant, and the rest is limited to parameter listing. It is brief but not inefficiently wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has simple parameters and no output schema, a short description might suffice. However, with no annotations and no behavioral context, the description is incomplete: it does not explain what the operation does beyond 'add', any consequences, or how it fits with related attachment tools. The agent is left without enough information to confidently use this tool in context.
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 input schema covers all three parameters with clear descriptions (case_id, filename, b64content) at 100% coverage, so the baseline is 3. The description's mention of 'filename plus base64 content' adds no new meaning beyond the schema's existing field descriptions, making it redundant but harmless.
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?
The description 'TestCase.add_attachment: filename plus base64 content' clearly indicates that this tool adds an attachment to a test case. It distinguishes itself from sibling attachment tools for plan, run, and execution by explicitly referencing 'TestCase', and the title 'Add case attachment' reinforces the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling attachment tools (e.g., kiwi_plan_add_attachment, kiwi_run_add_attachment, kiwi_execution_add_attachment). It does not mention any exclusions, prerequisites, or alternative scenarios, leaving the agent to infer based solely on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already informs the agent this is a safe read operation. The description adds the list of possible execution statuses (IDLE, PASSED, FAILED, BLOCKED) which gives useful domain context, though it does not describe pagination, filtering behavior, or return format beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short line, which is concise in word count, but it is more of a code snippet than a structured explanation. It lacks a clear front-loaded purpose statement and reads as under-specified rather than efficiently distilled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should convey what the tool returns; it only lists possible statuses without explaining the response structure or the meaning of 'filter'. The tool is simple, but the description leaves ambiguity about whether this returns all statuses or filters by the query parameter.
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 100%, so the parameters (limit and query) are fully documented in the schema. The description does not add anything beyond the status value list, which is not directly tied to the query parameter semantics, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title clearly states 'List execution statuses', but the description relies on a technical reference 'TestExecutionStatus.filter: IDLE, PASSED, FAILED, BLOCKED…' rather than an explicit verb. It implies the tool surfaces these status values but doesn't plainly describe the action, and it doesn't distinguish it from sibling list tools like kiwi_list_case_statuses beyond the resource named in the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context for when to use this tool versus alternatives, such as case statuses or execution lists. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint:true, so safety is known, but the description adds no behavioral context. It doesn't mention sorting, pagination, or that omitting query returns all users. The description only restates the username filter already present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a four-word fragment, which is concise but under-specified. It lacks the structure of a complete description and doesn't earn its place as a standalone sentence. It could be improved without adding verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns, but it doesn't. It also doesn't state whether an empty query returns all users or how the limit interacts. The tool is simple, but this description leaves too much unspecified.
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 schema has 100% coverage for both limit and query, including descriptions. The description's 'User.filter by username' adds no additional parameter semantics beyond the schema, so baseline 3 applies.
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?
The description 'User.filter by username' indicates the tool filters users by username, and the title 'List users' clarifies the action. However, the description is a cryptic fragment rather than a complete sentence, so it doesn't fully articulate the purpose on its own. It distinguishes from siblings by the username filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided in the description. There are no alternatives mentioned, nor any indication of when to use this tool over other list tools. The usage is only implied by the tool name and the query parameter description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only mentions 'logs, screenshots (base64)' which hints at content encoding but does not state whether attachments are appended, overwritten, or subject to permissions. No side effects or return behavior are described, making this minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and to the point, with no wasted words. However, it is under-specified rather than efficiently structured; it reads more like a stub than a well-crafted summary. It occupies the middle ground between appropriately concise and inadequately sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (3 required params, no output schema), the description is too thin to fully guide selection and invocation. It lacks usage context, behavioral details, and any mention of validation or response. The schema covers parameter mechanics but not the operational context needed for correct use.
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 coverage is 100%, with each parameter having a clear description. The description adds examples of use cases ('logs, screenshots') that relate to filename and b64content, but this is marginal beyond the schema. It does not elaborate on parameter relationships or additional format specifics.
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?
The description clearly identifies the tool as adding an attachment to a test execution, distinguishing it from sibling attachment tools for cases, plans, and runs. The examples 'logs, screenshots (base64)' give concrete context about intended content. It could be more explicit with 'adds' but the verb+resource is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling attachment tools (e.g., kiwi_case_add_attachment, kiwi_run_add_attachment). The description does not mention exclusions or alternative tools, leaving the agent to infer context solely from the 'TestExecution' prefix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states that it adds an arbitrary name/value pair, without detailing whether existing properties are overwritten, what the return value is, or any side effects or auth requirements.
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?
The description is a single, straightforward sentence that gets directly to the point. It contains no filler or redundant information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description needs to cover expected behavior and results. It omits important context such as what happens on duplicate properties, whether the operation is reversible, and what the response contains, leaving an agent with insufficient information for complex decision-making.
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 input schema has 100% coverage with clear descriptions for all parameters (name, value, case_id). The description adds minimal extra meaning via 'arbitrary', which is a slight reinforcement but not necessary given the schema already specifies string types and minLength.
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?
The description clearly references TestCase.add_property, indicating this adds a property to a test case. The phrase 'arbitrary name/value pair' clarifies the nature of the property, but it doesn't explicitly distinguish from sibling tools like kiwi_run_add_property or kiwi_execution_add_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kiwi_case_remove_property or kiwi_run_add_property. The usage is implicitly clear from the name, but there are no explicit context cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already conveys the read-only nature. The description adds only the default value for product, which is already documented in the input schema. It does not disclose any additional behavioral traits such as pagination, return format, ordering, or limitations.
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?
The description is very short and front-loaded, avoiding unnecessary verbosity. However, the first sentence is a noun phrase rather than a complete actionable statement, and the second sentence duplicates schema information, so it is concise but slightly under-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and minimal annotations, the description should at least clarify that a list of components is returned and what a 'component' is in this context. It lacks any information about response shape or edge cases, making it insufficient for confident invocation.
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 input schema fully documents both parameters (limit and product) with descriptions including defaults. The description simply restates the product default and adds no new semantic meaning beyond the schema, so a baseline of 3 is appropriate.
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?
The description identifies the resource (components) and scope (per product), making it distinguishable from sibling list tools. However, it lacks an explicit verb like 'list' or 'return', and the fragment 'Components for a product' is not a complete statement, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus other list tools among siblings (e.g., kiwi_list_plans, kiwi_list_runs). The only usage hint is the default behavior for the omitted product parameter, which is a parameter detail rather than an explicit usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It states the mutation but omits side effects, idempotency, or failure behavior (e.g., what happens if the tag doesn't exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a redundant prefix 'TestCase.add_tag' that repeats the tool name, followed by the useful sentence. It is short but wastes the first sentence on tautology, so not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no annotations or output schema, the description is inadequate: it doesn't state whether the tag must already exist, how duplicates are handled, or the success/failure response. The agent is left with significant unknowns.
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 schema already provides descriptions for both parameters (case_id, tag) with 100% coverage, so the description needn't explain them. It adds no additional meaning beyond confirming the action, so baseline 3 applies.
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?
The description 'Attaches a tag to the test case' uses a clear verb (attaches) and resource (test case), and the tool name disambiguates from run/plan tag tools. It distinguishes from sibling tools like kiwi_case_remove_tag and kiwi_run_add_tag by specifying 'case'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., tag must exist) or exclusions (e.g., for run tags use kiwi_run_add_tag).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does 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. It reveals that the operation is a mutation ('detaches') but does not explain side effects (e.g., whether the tag is deleted if it becomes unused), permanence, idempotency, or permissions. This is insufficient for a mutation tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and direct, but the first sentence 'TestCase.remove_tag' is redundant with the tool name and adds no value. The second sentence is concise and front-loaded, but the overall structure wastes a sentence without contributing new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema and no annotations, the description is too sparse. It does not explain what the tool returns, whether the operation is reversible, or what happens to the tag resource itself. The agent lacks essential context to handle errors or postconditions correctly, making the description incomplete for the tool's complexity.
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 input schema already covers 100% of parameters with descriptions ('Tag name' and 'Test case id'), so the description adds marginal semantic value beyond the schema. It only contextualizes the action as detaching from a case, which is already implied by the parameter names and schema descriptions, meeting the baseline for high schema coverage.
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?
The description clearly states a specific action ('Detaches a tag') and a specific resource ('from the test case'), differentiating it from sibling tools like kiwi_case_add_tag and kiwi_plan_remove_tag. The verb 'detaches' precisely indicates a removal of an association rather than deletion of the tag itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kiwi_plan_remove_tag or kiwi_run_remove_tag. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and the generic phrase 'from the test case.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does 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. It does not mention the destructive nature of the operation, the optionality of link_id, or the consequence that omitting link_id removes all links for the execution. These behaviors are only surfaced in the parameter descriptions, not in the main tool description.
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?
The description is a single, short sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to scan. All words earn their place, even though the description is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with no output schema, the description is somewhat under-specified. It does not explain the all-links removal behavior when execution_id is used without link_id, nor does it mention the irreversibility of the action. The lack of annotations makes the description responsible for providing this context, which it fails to do fully.
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 input schema has 100% coverage with both parameters described. The description adds no additional meaning beyond echoing 'by link id or execution_id', which is already implied by the schema. Since schema coverage is high, a baseline score of 3 is appropriate.
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?
The description 'TestExecution.remove_link by link id or execution_id' clearly states the action (remove) and resource (link), and the parameter options are briefly noted. It differentiates from sibling tools like kiwi_execution_add_link through the verb 'remove', but does not explicitly distinguish itself from other removal tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. It does not mention that this is for removing existing links, nor does it advise on choosing between link_id and execution_id. The description is purely functional and lacks contextual usage directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency, but it only states the core action. It does not disclose whether the tag must already exist, whether attaching is idempotent, or any side effects beyond the attachment.
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?
The description is extremely short, but it includes a redundant method identifier ('TestPlan.add_tag.') that adds no value. Otherwise, it is front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema. The description fails to mention that a separate tool exists to create tags, which is critical for correct usage. It is underspecified for a tool that modifies state.
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 coverage is 100% with descriptions for both 'plan_id' and 'tag'. The description adds no extra parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
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?
The description states a specific verb ('Attaches') and resource ('tag to the test plan'), clearly distinguishing it from sibling tools that add tags to runs or cases. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., adding tags to runs or cases). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is safe. The description adds useful behavioral detail about traversal order ('DFS order from the root'), which is beyond the annotations. However, it does not describe what the output contains or any error conditions, leaving some gaps.
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?
The description is a single concise sentence with no filler, which scores well for economy. However, it is so terse that it borders on under-specification; the 'ancestry' phrasing could be more explicit. Still, every word earns its place relative to the high-level purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and a read-only annotation, the description still leaves critical gaps: it does not specify the return format (e.g., list of nodes, tree object) or clarify the ambiguous 'ancestry' term. An agent would struggle to predict the tool's output or how plan_id is interpreted in the tree.
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 input schema fully documents plan_id as 'Test plan id' (100% coverage), so the schema carries the parameter meaning. The description does not add any additional context about how plan_id relates to the tree (e.g., whether it is the root or any node), so it neither improves nor harms the semantic clarity beyond the schema.
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?
The description states the resource (TestPlan.tree) and the key behavior (ancestry in DFS order from the root), which clearly distinguishes it from sibling tools like kiwi_list_plans. It is somewhat terse and lacks an explicit verb like 'get' or 'return', but the meaning is inferable for this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, exclusions, or a preferred context such as 'use when you need the plan hierarchy' or compare to kiwi_list_plans. The agent is left to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does 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. It states only that the attachment is deleted by id, but does not mention irreversibility, required permissions, cascading effects on parent items, or behavior when the id does not exist.
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?
The description is extremely concise, using only a few words to convey the action and target. It is front-loaded and contains no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter, no output schema, simple deletion action), the description is minimally sufficient. However, it leaves gaps around deletion semantics and usage context, so it is not fully complete for an agent to confidently invoke it in all relevant scenarios.
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 input schema already fully describes the single parameter attachment_id as 'Attachment id to delete', achieving 100% schema description coverage. The description adds no meaningful semantic beyond what the schema provides, so the baseline score of 3 applies.
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?
The description clearly states a specific action ('remove attachment') and the target resource ('Attachment') with the mechanism ('by id'). It is immediately understandable, though it does not explicitly differentiate itself from sibling tools like kiwi_case_remove_attachment or kiwi_plan_remove_attachment beyond the id-based approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this generic remove-by-id tool versus the parent-specific attachment removal tools among siblings. The description implies usage only if you have an attachment_id, but offers no context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It reveals that status can be an id or name resolved from the execution run and that comments are handled via a separate add_comment call, but it does not disclose side effects, permission requirements, or behavior when conflicting parameters are provided. This is insufficient for a mutation tool.
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?
The description is a single, compact sentence that covers the core purpose and key fields. It wastes little space, though the leading 'TestExecution.update:' is internal jargon that repeats the title and could be omitted for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a good overview of what can be updated and mentions the optional comment, but it lacks usage guidance, return value details, and behavioral caveats. Given the 8-parameter schema and no output schema or annotations, the description is adequate but leaves notable gaps.
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?
The input schema has 100% coverage, so the baseline is 3. The description adds meaningful context by clarifying that status accepts either id or name resolved from the execution run, and that the comment parameter triggers a separate TestExecution.add_comment operation. This goes beyond the schema's individual parameter descriptions.
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?
The description clearly states the tool updates a TestExecution and lists the updatable fields (status, build, assignee, dates). It also mentions the optional comment feature. However, it does not explicitly contrast with sibling update tools like kiwi_update_run or kiwi_update_case, so differentiation relies mostly on the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It notes that a comment can be added via TestExecution.add_comment, implying a separate operation, but it does not state when to prefer this tool over kiwi_execution_add_comment or other update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It lists updatable fields but does not explain partial update semantics (whether unspecified fields are preserved), permissions required, error behavior, or response format. The description only names fields and provides no additional context.
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?
The description is a single, compact sentence with no unnecessary words. It front-loads the action and lists all key fields. However, it is so terse that it borders on cryptic, but it earns its place by being efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and no output schema, the description is insufficient. It does not explain that the 'id' parameter is required, how the update behaves (e.g., partial vs. full replacement), or what is returned. The sibling list includes create and update tools, but the description does not help differentiate or provide essential operational context.
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 100%, so the schema already documents all parameters in detail. The description merely repeats field names ('name, type, product, version, text, active flag') without adding extra meaning, such as relationships or constraints. It does not compensate for the schema's coverage, so a baseline of 3 is appropriate.
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?
The description 'TestPlan.update' is a specific verb+resource pairing that clearly indicates updating a test plan. The title 'Update test plan' reinforces this, and the listed fields (name, type, product, version, text, active flag) distinguish it from sibling tools like kiwi_create_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or differences from related tools like kiwi_create_plan or kiwi_update_case. The API method line implies usage but offers no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'Returns' is consistent. It adds that omitting case_id broadens the listing, which is useful, but doesn't describe output structure or potential edge cases.
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?
The description is very brief with only two meaningful clauses. The leading 'TestCase.properties.' is ambiguous and could be replaced with more explicit language, but there is no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description gives a basic idea of return type (name/value) but leaves ambiguity around the exact format and scope of 'more broadly'. It is adequate but could be clearer.
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 input schema already provides full descriptions for case_id (100% coverage), including the omit-to-list-without-filter behavior. The description essentially restates this, adding no new semantic information.
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?
The description uses 'Returns name/value properties' which clearly states the action and resource. The mention of 'case_id' distinguishes it as case-related, though the opening 'TestCase.properties' is somewhat cryptic and could confuse an agent. It does not explicitly differentiate from run/execution property tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs kiwi_run_properties or kiwi_execution_properties. The only usage hint is about omitting case_id, which is more parameter behavior than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint:false, so the description carries the burden. It discloses a key default (product defaults to KIWI_PROJECT) but does not mention side effects, required permissions, or return behavior. This adds some behavioral context but leaves significant gaps.
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?
The description is a single concise sentence, easy to scan. However, 'Version.create' is a bit cryptic and could be clearer, but it is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description should explain what is returned or what success looks like. It only describes the input behavior and default, leaving the outcome unspecified. This is a notable gap for agents deciding whether to invoke the tool.
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?
The schema already documents both parameters, but the description adds the default value for product (KIWI_PROJECT), which is not in the schema. This enhances understanding of the product parameter and its optionality.
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?
The description states 'Version.create' and 'value plus product', making it clear this tool creates a version. It is distinct from sibling kiwi_list_versions. However, the wording is terse and relies on the title for full clarity, so not 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios or exclusions, and the sibling list contains no related create tool except this one, but that doesn't substitute for explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation readOnlyHint=true already signals safe read operation. Description adds return-value context (metadata and download URLs), but does not disclose potential pagination, empty results, or permission requirements; still consistent with annotations.
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?
The second sentence is informative and concise, but the first sentence 'TestExecution.list_attachments' is redundant with the tool name. Overall it is short and front-loaded enough to be usable.
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 simple read-only list operation with one well-documented parameter, the description adequately indicates what is returned (metadata and download URLs). No output schema exists, so mentioning return payload is beneficial; minor gaps like empty-list handling are acceptable.
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 covers execution_id with description 'Test execution id' at 100% coverage, so the description adds little beyond schema. It does not elaborate on how to obtain the execution_id or format expectations, but baseline 3 is warranted.
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?
Description explicitly says 'Returns attachment metadata and download URLs' for TestExecution, making the verb and resource clear. It does not explicitly contrast with sibling attachment-list tools for case/plan/run, though the tool name and 'TestExecution' prefix provide some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus kiwi_case_list_attachments, kiwi_plan_list_attachments, or kiwi_run_list_attachments. The description simply states what it does without recommending usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation. The description adds minimal context about the returned fields (execution_id and status) but does not disclose pagination, ordering, or other behavioral traits. It does not contradict the annotation.
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?
The description is a single concise sentence, but the leading 'TestRun.get_cases:' is redundant with the tool name and consumes space. The core phrase 'run cases with execution_id and status' is brief but could be clearer. Overall, it is short and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should compensate by explaining return structure. It mentions execution_id and status but does not state whether the result is a list, how cases are ordered, or potential limitations. Given the simplicity of the tool (one parameter, read-only), this is adequate but not complete.
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 schema fully documents the only parameter run_id as 'Test run id' (100% coverage). The description does not add additional meaning or contextual constraints beyond what is already in the schema, so the baseline of 3 is appropriate.
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?
The description indicates the tool retrieves run cases with execution_id and status, matching the name and title. However, the phrase 'run cases' is ambiguous (could be read as a verb phrase meaning to execute tests), and it doesn't explicitly distinguish from sibling tools like kiwi_list_runs or kiwi_run_add_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kiwi_list_runs or kiwi_search_cases. There is no mention of exclusions, prerequisites, or typical use cases beyond the implied 'get cases for a run'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds that the return includes metadata and download URLs, which is useful but does not disclose potential pagination, ordering, or data volume. This is adequate but not rich.
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?
The description is two short sentences with no wasted words. The first sentence is somewhat redundant with the title, but it is not harmful. Overall, it is front-loaded and efficient.
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 simple 1-parameter read-only list operation, the description covers the essential return shape (metadata and download URLs) and the schema covers the parameter. Given the lack of an output schema, this is sufficient, though mentioning pagination or sorting would have made it more complete.
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 coverage is 100% with a clear description for the single run_id parameter, so the description carries no additional parameter burden. The tool description adds no parameter-specific context, but none is needed given the schema's completeness.
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?
The description clearly states it returns attachment metadata and download URLs, and the 'TestRun' prefix indicates it operates on runs, distinguishing it from sibling attachment-listing tools for cases, plans, and executions. However, the first sentence mostly restates the method name, and the run scope is only implied, not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like kiwi_case_list_attachments or kiwi_plan_list_attachments. There is no exclusionary context or mention of prerequisites, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a read operation, lowering the burden. The description adds useful behavioral context about what the stats include (breakdown by status and failed executions), but doesn't detail return format or any potential limitations. No contradiction with annotations.
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?
The description is a single sentence with no fluff, but it uses internal jargon ('TestRun.filter', 'TestExecution') that may not be transparent. It is front-loaded with 'Aggregated run stats' which conveys the core purpose, making it efficient though slightly cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description conveys the main output (aggregated stats with status breakdown and failed executions). However, it lacks detail on the exact response structure or how data is grouped, which could be relevant for an agent. It is minimal but adequate.
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 covers run_id with a clear description ('Test run id'), so the description adds no additional parameter semantics. Baseline 3 applies with high schema coverage. The tool's single parameter is straightforward.
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?
The description clearly indicates the tool provides aggregated run statistics including status breakdown and failed executions. However, it's phrased as a noun phrase ('Aggregated run stats') rather than an explicit verb like 'Get' or 'Retrieve', slightly reducing action clarity. It distinguishes itself from sibling tools like kiwi_list_executions by focusing on aggregated summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description mentions TestRun.filter and TestExecution breakdown, but doesn't state that this should be used for summary statistics while kiwi_list_executions provides detailed execution data. Missing explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint=false, which is minimal. The description adds one behavioral nuance: build accepts a name looked up on the product/KIWI_PROJECT, and manager accepts a username. This provides useful context beyond the annotation, but it does not disclose return values, permissions, or prerequisites for the creation, leaving some behavioral aspects unclear.
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?
The description is only two sentences and avoids unnecessary repetition. The first sentence states the core purpose, and the second provides a key parameter nuance. It is concise, though the phrasing 'TestRun.create for a plan and build' is a bit terse and could be clearer for agents unfamiliar with the Kiwi domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and no output schema, the description offers the crucial detail about build name resolution but does not address return values, whether the plan and build must already exist, or the role of notes/default_tester. The schema covers parameter descriptions, but for a create operation, the description could be more complete to ensure correct invocation.
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?
The input schema has 100% coverage for all parameters, so the schema already explains each field. The description goes further by clarifying that 'build' accepts a name that is resolved against the product/KIWI_PROJECT and 'manager' accepts a username, adding helpful context about how parameter values are interpreted. This is valuable beyond the schema descriptions.
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?
The title 'Create test run' and description 'TestRun.create for a plan and build' clearly indicate the tool creates a test run referencing a plan and build. The verb and resource are specific, and it distinguishes from sibling create tools by mentioning the required inputs. However, 'TestRun.create' is somewhat terse and assumes familiarity with Kiwi's API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The name implies it is for creating a test run, but the description does not mention when to prefer it over update_run or other create tools, nor does it provide exclusions or alternative tool suggestions. Usage is only inferred from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does 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, but it only says 'adds' without detailing side effects, idempotency, duplicate handling, or authentication requirements. It is not misleading but is largely silent on behavior beyond the basic operation.
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?
The description is a single, short sentence that conveys the core purpose without fluff. It is front-loaded and appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (three simple parameters) and lack of output schema, the description covers the essential purpose but omits operational details like return value and duplicate behavior. It is adequate for basic invocation but not fully complete for an agent to anticipate outcomes.
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 input schema already provides complete descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds no additional meaning beyond what the schema states, as 'name/value' simply mirrors the parameter descriptions.
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?
The description clearly states the action ('Adds a name/value property') and the target resource ('execution'), which differentiates it from sibling tools like kiwi_run_add_property and kiwi_case_add_property. The verb+resource structure is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention when to add properties to executions vs cases/runs, nor when to prefer adding links over properties. The description simply states the action without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only annotation covers the safety profile, but the description adds no additional behavioral context such as pagination, permissions, or effects of omitting the execution filter. It merely restates the return type, which is already evident from annotations.
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?
The description is short and front-loaded, but the opening phrase 'TestExecution.properties.' is cryptic and adds little value beyond the restated purpose.
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 low-complexity read-only list tool, the combination of description, schema, and annotation is sufficient. The return format (name/value pairs) is indicated, and the optional parameter is fully documented.
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 input schema fully documents the single optional parameter (execution_id) with a clear description, so the schema carries the burden. The tool description contributes no additional parameter meaning.
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?
The description clearly states the tool returns name/value properties for a given execution, distinguishing it from sibling property tools for runs and cases. The verb 'Returns' and the title 'List' specify the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like kiwi_run_properties or kiwi_case_properties. The description only restates the resource type; the parameter hint about omitting execution_id is in the schema, not the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already declares the safe read-only nature of the operation. The description adds that filtering is possible by run, case, status, and assignee, consistent with read-only behavior. It does not disclose additional behavioral traits such as result ordering or pagination, but the schema covers the limit parameter. This meets the baseline given the annotation coverage.
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?
The description is a single short sentence that conveys the core purpose without any wasted words. It is front-loaded and highly efficient, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple filtered list operation with all parameters documented in the schema and a read-only annotation supplied. However, the description does not explain how this tool fits among the many sibling tools (e.g., when to search executions versus runs), nor does it mention the return format. Given the annotations and schema, it is minimally complete but lacks broader contextual guidance.
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 input schema provides detailed descriptions for all five parameters, achieving 100% coverage. The tool description merely mentions four of these parameters without adding any semantic value beyond what the schema already provides. Thus it meets the baseline for high schema coverage but does not enhance parameter understanding.
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?
The description 'TestExecution.filter by run, case, status, and assignee' clearly identifies a filtering operation on TestExecution resources and lists the filter dimensions. The title 'Search executions' reinforces the purpose. While it does not use the word 'list', 'filter' implies retrieval and distinguishes from siblings like kiwi_list_runs, which target runs rather than executions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as kiwi_list_runs or kiwi_run_get_cases. It does not mention exclusions or say 'use this when you need to search executions by specific criteria'. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read behavior is known. The description adds no behavioral context beyond that; 'Version.filter.' is obscure and the requirement note does not explain how the tool behaves internally or what it returns. Thus it fails to meaningfully enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and the second sentence about being required for TestPlan.create and Build.create is valuable. However, the first sentence 'Version.filter.' is a cryptic fragment that adds little value and is not well structured, so it is not concise in an effective way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three documented parameters and no output schema. The description provides important dependency information but does not explain the return structure or filtering behavior beyond the schema. It is adequate but leaves gaps for an agent unfamiliar with Kiwi.
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?
All three parameters (limit, query, product) have schema descriptions, covering 100% of the parameters, so the description does not need to repeat them. The description adds no additional parameter-level detail, yielding a baseline score of 3.
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?
The title 'List product versions' clearly states the purpose, and the description adds that it is a version filter required for creating test plans and builds. However, 'Version.filter.' is a cryptic fragment that lacks a clear verb, and no explicit distinction from sibling list tools is made.
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 description provides explicit context by stating it is required for TestPlan.create and Build.create, telling the agent when to use this tool. It does not mention alternatives or exclusions, but there are no direct sibling tools for listing versions, so this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action and input format, but does not mention potential side effects, required permissions, size limits, or response behavior. For a mutating upload operation, this is a notable gap.
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?
The description is short and immediately conveys the core function. The first sentence ('TestPlan.add_attachment.') is redundant with the tool name, but the second sentence is efficient and informative. Overall, it is reasonably concise with no fluff.
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 simple upload tool, the description and rich schema cover the essential details: what is uploaded, in what format, and to what target. No output schema is present, but the tool's behavior is straightforward enough that this does not severely hamper usability. A small amount of additional context about side effects or return values would improve it.
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 coverage is 100% with each parameter already described (plan_id, filename, b64content). The description's mention of 'filename + base64 content' mirrors the schema, adding little new meaning. The baseline of 3 applies because the schema is fully self-explanatory.
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?
The description clearly states the tool's function with a specific verb ('Uploads') and resource ('the plan'), and explicitly names the payload (filename + base64 content). It differentiates this from sibling attachment tools by scoping to 'plan', matching the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like case_add_attachment or run_add_attachment. The context signals list many sibling attachment tools, but the description does not explain when this one is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full transparency burden. It only states that the tool attaches a case to a plan, but does not disclose idempotency, duplicate handling, required preconditions, or side effects—critical gaps for a mutation tool.
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?
The description is a single, direct sentence that efficiently conveys the action. The 'TestPlan.add_case' prefix provides useful API context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters and no output schema. The description covers the core action but omits usage context and behavioral details, making it minimally viable but not fully complete for confident invocation.
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 schema already provides full descriptions for both parameters (case_id and plan_id), so the description adds no additional semantic value. The baseline score of 3 applies because the schema coverage is 100%.
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?
The description uses the specific verb 'attach' and explicitly names both the object (test case) and destination (test plan), clearly distinguishing it from sibling tools like kiwi_run_add_case and kiwi_plan_remove_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kiwi_run_add_case or kiwi_plan_remove_case. There are no exclusions, prerequisites, or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects (e.g., whether existing properties are overwritten), permissions required, or error conditions. This is a significant gap for a mutating operation.
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?
The description is exceptionally concise with two short sentences. The first sentence ('TestRun.add_property') provides a domain anchor, and the second clearly states the action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 3 fully described parameters, but there are no annotations and no output schema. The description does not explain the return value, duplicate handling, or success/failure indication, leaving some context gaps. However, given the trivial nature of the operation, this is minimally adequate.
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 100%, so the schema already documents all three parameters (name, value, run_id). The description adds no extra semantic detail beyond confirming that name and value form a property pair. This meets the baseline for high schema coverage.
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?
The description clearly states a specific action ('Adds a name/value property') on a specific resource ('the test run'). It distinguishes from sibling tools like kiwi_run_add_tag (adds a tag) or kiwi_case_add_property (adds to a case) by clearly scoping to test runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kiwi_case_add_property or kiwi_execution_add_property. The tool name implies context, but there is no explicit when/when-not guidance or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds context that it returns the full change history and references KiwiHistoricalRecords, but does not disclose additional behaviors such as pagination behavior, ordering, or whether the result is paginated. It offers some value beyond the annotation but not extensive context.
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?
The description is a single, short sentence that conveys the core purpose without wasted words. It is front-loaded and appropriately sized for the tool's simplicity.
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 simple read-only tool with one required parameter and an optional limit, the description is adequate. It names the return type (KiwiHistoricalRecords) and the schema covers parameter details. It could mention result ordering or default limit, but those are already partially covered by the schema. Overall, it is sufficiently complete for this level of complexity.
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 100%, with both parameters (id and limit) clearly described. The description itself adds no parameter information, but the schema already handles semantics, so the baseline score of 3 applies.
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?
The description clearly identifies the tool as providing test case history, specifically 'full change history' via KiwiHistoricalRecords. It implies a retrieval action, though it lacks an explicit verb like 'get' or 'list'. It distinguishes from siblings by focusing on historical records rather than current case details or modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, complementary tools, or scenarios where another tool would be more appropriate. The description simply states what it does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint: false, so the description carries some burden. It adds the product default (KIWI_PROJECT) and mentions the type, which are useful behavioral details. However, it does not disclose side effects, permissions, return values, or behavior on success/failure, leaving significant gaps.
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?
The description is a single sentence of 12 words, immediately front-loads the core action, and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values or expected outcomes; it does not. It also omits prerequisites (e.g., whether the plan type must exist) and any post-creation behavior. However, it is a relatively simple create operation, and the parameter schema covers field details, making it minimally adequate but not complete.
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 100%, so the schema already documents all parameters. The description repeats the product default and type context but adds no new parameter semantics beyond what the schema provides. Baseline 3 is appropriate given the high schema coverage.
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?
The description clearly states the action (TestPlan.create) and the resource (TestPlan), and differentiates from sibling tools like kiwi_create_run or kiwi_create_plan_type by specifying the object being created. It also adds context about the product and type, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It merely restates the purpose without mentioning when not to use it or which sibling tool to choose instead. The name and title imply usage, but the description itself lacks contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint: true, but the description adds no behavioral information beyond that. It does not disclose pagination or return format, sorting, or how filters combine. The description essentially restates the schema's filter fields, offering no new insight into the tool's runtime behavior.
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?
One terse fragment condenses the tool's purpose and filters into a single line. No wasted words, front-loads the resource ('TestRun') and action ('filter').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list/filter operation with full schema descriptions and a read-only annotation, but lacks an output schema. The description does not mention that it returns a list of runs, how many, or the default behavior when no filters are applied. However, the name and schema infer the basics. It is adequate but not complete for an agent to fully understand the tool's behavior without further inference.
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?
All 6 parameters have descriptions in the schema, achieving 100% coverage. The description merely lists the filter fields (summary, plan, build, product, still open) without adding extra semantic detail. It omits the 'limit' parameter entirely. Therefore, the description adds no value beyond the schema, but the schema is complete, so a baseline of 3 is warranted.
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?
The description states 'TestRun.filter by summary, plan, build, product, and whether still open,' which clearly identifies the tool as a search/filter operation on TestRun entities. It lists specific filter dimensions, distinguishing it from sibling tools like kiwi_create_run or kiwi_list_executions. The title 'Search test runs' reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as kiwi_run_status or kiwi_list_executions. The filter criteria imply usage for searching/filtering runs, but no exclusions or alternative recommendations are given. Context is only implied by the name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral disclosure. It only states the operation ('detaches a tag') and does not explain consequences (e.g., idempotency, error handling if tag is not attached, or permission requirements). This is a significant gap for a mutation tool.
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?
The description is concise, two short phrases. The first part is a method reference, the second a clear action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter operation, the description conveys the core purpose, but it lacks context about side effects, usage boundaries, or behaviors when tags are missing. Given no annotations and no output schema, the description could be more complete.
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 schema provides descriptions for both parameters (plan_id, tag) with 100% coverage, so the description doesn't need to repeat them. It does not add any additional semantic value beyond what the schema already states. Baseline 3 is appropriate.
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?
The description clearly states the action ('Detaches a tag from the test plan') and identifies the resource (test plan). The title and mention of 'TestPlan' differentiate it from tag removal on run or case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance about when to use this tool versus alternatives like kiwi_run_remove_tag or kiwi_case_remove_tag, though the scope to 'test plan' is implied. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral details such as idempotency, error conditions, whether the tag must already exist, or if duplicate tags are allowed. This is a mutation tool and the description is silent on side effects.
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?
The description is a single, front-loaded sentence with no wasted words. It delivers the essential purpose without redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two parameters, no output schema), the description is minimal but lacks important context such as return behavior, error handling, or preconditions. The schema covers parameters well, but the absence of behavioral disclosure leaves gaps for a mutation tool.
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 input schema provides complete descriptions for both parameters (tag name and run id) with 100% coverage. The description adds no additional parameter context, but the schema already carries the semantic burden, warranting the baseline score of 3.
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?
The description clearly states the action ('Attaches a tag') and the target resource ('to the test run'), distinguishing it from sibling tools that add tags to plans or cases. This is a specific verb+resource combination with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to tag a run, but provides no explicit guidance on when to choose this tool over alternatives like kiwi_plan_add_tag or kiwi_case_add_tag. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the mutation ('detaches') but does not mention error behaviors (e.g., when the tag is not attached), idempotency, or return value, leaving the agent with incomplete expectations.
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?
The description is only two short sentences, front-loaded with the method name and a clear verb phrase. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters, the description is adequate but lacks details about output or edge cases. With no output schema and no annotations, an agent may not know what to expect after invocation, but the simplicity keeps the gap modest.
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 100% (both run_id and tag have descriptions), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
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?
The description clearly states the action ('Detaches a tag') and the resource ('test run'), which distinguishes it from sibling tag-removal tools for plans and cases. The inclusion of the API method name 'TestRun.remove_tag' reinforces the specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's purpose (remove a tag from a run) but provides no explicit guidance on when to use it versus alternatives like kiwi_plan_remove_tag or kiwi_case_remove_tag. There are no exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only destructiveHint=false in annotations, the description should provide additional behavioral context, but it does not. It states that it 'adds' a type but says nothing about idempotency, duplicate name handling, permissions, or side effects. The examples are informative but not behavioral traits.
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?
The description is only two short sentences with no fluff. 'PlanType.create' is a compact prefix, and the second sentence clarifies the action with concrete examples. Every word earns its place.
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 simple two-parameter create tool with no output schema, the description is adequate for basic understanding. It clearly states the purpose and gives examples, though it could mention potential duplicate handling or its role in test plans. Given the low complexity, this is nearly complete.
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 input schema provides 100% coverage for both parameters, including descriptions for 'name' and 'description'. The tool description adds the example 'Functional or Acceptance', which slightly extends the schema's 'e.g. Functional', but the baseline is already met by the schema alone.
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?
The description explicitly states 'Adds a new TestPlan type' with concrete examples (Functional, Acceptance) and uses 'PlanType.create' to identify the resource and action. This clearly distinguishes it from sibling tools like kiwi_create_plan (creates a plan) and kiwi_list_plan_types (lists types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating a plan type, but it does not explicitly state when to use it versus alternatives or provide any exclusions. It lacks guidance on prerequisites or scenarios where another tool would be more appropriate, so the usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It reveals that the operation unlinks rather than deletes, but omits side effects, permissions, idempotency, and error behavior. This is minimal disclosure.
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?
The description is concise, but the opening 'TestPlan.remove_case.' simply repeats the tool name and adds little value. The main sentence is direct and free of extraneous detail, earning a high but not perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter removal operation, the description covers the core function and parameters. However, without annotations or an output schema, it lacks behavioral context like error handling or idempotency, which could matter for agent decision-making.
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 schema provides full coverage for both parameters (plan_id and case_id), so the baseline is 3. The description adds no new parameter semantics beyond mapping 'given plan' and 'test case' to the respective IDs.
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?
The description clearly states the action with the verb 'Unlinks' and specifies the resource: a test case from the given plan. This distinguishes it from siblings like kiwi_plan_add_case and kiwi_plan_update_case_order, so the purpose is unambiguous.
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 description gives clear context for when to use the tool (when a test case needs to be unlinked from a plan), but it does not explicitly mention alternatives or exclusion criteria. This is clear context without formal when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and parameters, but omits any mention of permissions, error conditions, whether it is a mutation, or what response to expect. This is a significant gap for a write operation.
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?
The description is a single, well-structured sentence with no filler. It front-loads the action and key parameters, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must cover return behavior and side effects. It does neither, leaving the agent uncertain about what happens after a successful upload. The simple schema mitigates some incompleteness, but the missing return information is a notable gap.
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 input schema already covers all three parameters (run_id, filename, b64content) with clear descriptions, so the description adds minimal semantic value. With 100% schema coverage, the baseline of 3 is appropriate.
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?
The description clearly states the action ('Uploads a file') and the target resource ('to the run'), distinguishing it from sibling tools targeting cases, plans, or executions. The 'TestRun.add_attachment' reference further reinforces the specific API method.
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 description gives clear context that this tool is for run attachments, implying when it should be used in relation to the many sibling attachment tools. However, it does not provide explicit exclusions or alternative guidance beyond the resource target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the safety profile is covered. The description adds the substring filter behavior but does not disclose return format, pagination, or other behavioral details beyond what annotations and schema already communicate.
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?
The description is extremely concise and front-loaded. However, the fragment 'Tag.filter.' adds minimal value and is somewhat cryptic, slightly detracting from overall clarity.
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 simple read-only list tool with an annotation and complete schema, the description is adequate. It clearly states the operation and filter, though it omits exact return format, which is a minor gap.
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 100% with both 'limit' and 'query' documented. The description only echoes the query semantics and adds no additional meaning beyond the schema 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?
The description uses the specific verb 'Search' with resource 'tags' and scope 'by name substring', clearly stating what the tool does. It differentiates from sibling kiwi_create_tag, which is a creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied ('Search tags by name substring') but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, which already communicates safety. The description adds that the operation returns attachment metadata and download URLs, providing some context beyond the annotation. However, it does not disclose other behavioral details such as pagination or permission requirements. No contradiction with annotations.
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?
The description is a single, concise sentence that includes the method name and return type without any unnecessary words. It is front-loaded and efficient.
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 simple read-only tool with one parameter and no output schema, the description adequately specifies the return type (metadata and download URLs). It does not enumerate metadata fields or list format, but the simplicity of the tool makes this a minor gap, and annotations plus schema cover other aspects.
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 input schema fully describes the only parameter, case_id, with an integer type and description 'Test case id' (100% coverage). The description adds no parameter information beyond what the schema already provides, so the baseline score of 3 applies.
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?
The description explicitly states 'TestCase.list_attachments' and says it returns attachment metadata and download URLs, clearly identifying the verb (list), resource (case attachments), and output. This distinguishes it from sibling attachment tools for plans, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope is implied by the tool name and description mentioning 'case', but there is no explicit guidance on when to use this tool versus alternatives like kiwi_plan_list_attachments or kiwi_run_list_attachments. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The word 'unlinks' suggests a non-destructive action (vs. deleting the component), but no details are given about side effects, error conditions, or whether the component must already exist.
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?
The description is two short sentences with no filler. The method reference 'TestCase.remove_component' is slightly redundant with the title, but the overall structure is efficient and front-loaded with the action.
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?
Given the tool's simplicity (two integer params, no output schema) and full schema coverage, the description is adequate. It clearly states the action and resource, though it lacks edge-case details or explicit behavior notes, which are not critical for this straightforward operation.
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 schema provides 100% coverage for both parameters (case_id and component_id) with descriptions. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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?
Description uses a specific verb 'Unlinks' and identifies the resource 'component from the test case', clearly distinguishing it from the sibling tool kiwi_case_add_component. The purpose is unambiguous and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for removing a component-case association, but does not explicitly state when to use this tool over alternatives or mention prerequisites like the component needing to be linked. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=false already indicates a non-destructive operation. The description adds that the tag is intended for later attachment, but does not disclose details such as behavior on duplicate names or return values. It provides minimal additional behavioral context beyond the annotation.
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 short sentences, front-loaded with the core action. No redundant information.
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-parameter create tool with no output schema, the description covers the core action and the tag's purpose. It could mention uniqueness or return value, but given the simplicity, it is reasonably complete.
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 input schema fully documents the single 'name' parameter (required string, minLength 1). The description does not add any additional semantic detail about the parameter, so it scores at the baseline for high schema coverage.
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?
The description uses a specific verb ('Creates') and identifies the resource ('a tag') plus its intended usage ('can later be attached to cases, plans, or runs'). This clearly distinguishes from sibling tools like kiwi_list_tags (listing) and kiwi_case_add_tag (attaching an existing tag).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is a prerequisite for attaching tags, but does not explicitly state when to use it versus alternatives or mention any exclusions. It lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is already established, lowering the bar. The description adds the default-to-KIWI_PROJECT behavior, but this is also present in the schema; no other behavioral traits like pagination or response format are disclosed.
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?
The description is a single, concise sentence that communicates the core purpose and a key default. It is front-loaded and contains no wasted words.
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 simple list tool with fully documented parameters and a read-only annotation, the description is sufficiently complete. It could explicitly mention return type or filtering behavior, but these are implied by the tool name and schema.
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?
All three parameters have full schema descriptions (100% coverage), so the baseline is 3. The description repeats the product parameter's default but adds no new meaning beyond what the schema already provides.
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?
The description clearly indicates the tool returns builds for a product and highlights the default project behavior. It identifies the resource ('builds') and distinguishes from sibling list tools for other entities, though it lacks an explicit verb like 'list'.
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?
It provides context on the product parameter defaulting to KIWI_PROJECT, indicating the intended usage scope. No explicit alternatives or exclusions are given, so it falls just short of the highest rating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds the product default behavior. This is useful context beyond the annotation, though it does not disclose other specifics like pagination or return format.
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?
The description is a single short phrase that wastes no words and communicates the core concept instantly. It is appropriately sized for a simple list tool.
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 simple list tool with no output schema and fully documented params, this description is sufficient to understand what it does and its default behavior. A bit more detail on return values or typical use could improve it, but it is not incomplete for the complexity level.
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 100%, with both parameters already documented. The description merely restates the product default from the schema, adding no new semantic meaning beyond what the schema provides.
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?
The description identifies the resource (test-case categories) and the product scoping, but lacks an explicit verb like 'list'; the action is implied by the tool name/title. It does not explicitly differentiate from sibling list tools, though 'categories' is a distinct resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a useful default context ('Defaults to KIWI_PROJECT when product is omitted'), which implies when this tool is used. However, it does not explicitly state when to choose this over alternatives like kiwi_list_tags or kiwi_list_classifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It does mention the key side effect that TestExecutions are created, which is useful. However, it omits behavioral details such as idempotency, duplicate handling, required permissions, or error behavior, which limits transparency for a mutating operation.
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?
The description is a single sentence and very concise. The 'TestRun.add_case:' prefix is somewhat redundant with the tool name, but it is not verbose and the core message is front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two parameters and no output schema, the description covers the essential purpose and side effect. However, it does not address what happens with invalid or duplicate case IDs, nor the response format, leaving some gaps for an agent to infer.
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 100%: run_id is described as 'Test run id' and case_ids as 'Comma-separated case ids, e.g. 12,34,56'. The tool description adds no new parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.
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?
The description uses a specific verb ('add') and resource ('cases to the run'), clearly distinguishing it from run-related siblings like kiwi_run_add_tag or kiwi_run_get_cases. It also explains the underlying effect ('creates TestExecutions'), which further disambiguates from plan-related tools.
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 description makes the use case obvious (adding cases to a test run) and the tool name matches the title. However, it does not explicitly state when NOT to use it (e.g., for plans) or name alternatives, though the sibling list implies such distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint: false. The description adds the default behavior of version (defaults to first product version) and that version can be a name or id. However, it does not address other behavioral aspects like product defaults (though the schema mentions KIWI_PROJECT), is_active default, or what the response contains. Given the sparse annotations, the description carries some but not full burden.
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?
The description is a single, front-loaded sentence that immediately states the function ('Build.create') and essential parameters. It is concise with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters and no output schema, the description is adequate but incomplete. It does not explain the product default (KIWI_PROJECT, which is only in the schema), the is_active parameter behavior, or what the tool returns upon creation. For a create operation, an agent might need more context on response and defaults.
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?
The schema already covers all four parameters with descriptions (100% coverage). The description adds value by clarifying that the version parameter accepts either a name or an id, and that it defaults to the first product version. This goes beyond the schema's 'Version value or id' but does not add further semantics for other parameters.
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?
The description clearly states 'Build.create' with a specific verb and resource, and explains the required inputs (name plus version). This distinguishes it from sibling tools like kiwi_list_builds (listing) and kiwi_create_version (creating versions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implicit: it's a creation tool. However, there is no explicit guidance on when to use it instead of alternatives like kiwi_create_version or kiwi_list_builds. The description implies the tool is for creating a build, but lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds one useful behavioral insight: setting stop_date closes the run. However, it does not mention whether the update is partial or full, any permissions needed, or what the response contains. It provides minimal behavioral context beyond the mutation itself.
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?
The description is a single concise sentence, front-loaded with the operation name 'TestRun.update' and followed by a compact list of fields and a key hint. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with 8 parameters and no output schema or annotations, the description gives a good high-level overview but omits details about return values, partial-update behavior, or prerequisites. The stop_date hint adds context, but the tool remains somewhat underspecified for an AI agent to fully anticipate the result of invocation.
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 100%, so the baseline is 3. The description repeats field names already documented in the schema and explicitly mentions the stop_date effect that the schema already describes ('Set this to close the run'). No additional parameter semantics are provided beyond the schema.
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?
The description 'TestRun.update' clearly identifies the tool as an update operation on a test run, using a specific verb and resource. This distinguishes it from siblings like 'kiwi_create_run' (create) and 'kiwi_update_execution' (update execution). The list of fields (summary, notes, build, manager, dates) further clarifies the scope.
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 description provides clear context: it updates a test run. It also gives a specific usage tip ('set stop_date to close the run'). However, it does not explicitly state when not to use it or mention alternatives, such as using kiwi_update_execution for execution-level updates. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, which already signals a safe read operation. The description adds value by specifying the types of URLs returned (bugs, reports, CI) and the endpoint name, giving the agent a clearer picture of the result content without contradicting the annotation.
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?
The description is a single short sentence that conveys the essential information with no redundant words. It front-loads the action and resource.
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 simple read-only tool with one parameter and no output schema, the description provides sufficient context about the tool's purpose and the content of the results. It could mention return format, but the examples and endpoint reference make it adequate.
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 input schema provides a complete description for execution_id ('Test execution id'), so the baseline is 3. The description does not add parameter-specific details beyond indicating the URLs are attached to the execution, which is already implied by the parameter name and schema.
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?
The description uses a specific verb 'Returns' and identifies the resource as 'URLs attached to the execution', with concrete examples (bugs, reports, CI). This clearly distinguishes it from sibling mutation tools like add_link and remove_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, but the phrasing implies it is the read operation for execution links. It does not name alternative tools or provide exclusion criteria, so it earns only an implied-usage score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which is a key behavioral trait. The description adds valuable context about the return format ('text returned as-is (Markdown)') and the optional executions, which enriches understanding of the behavior. No contradictions with annotations.
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?
The description is a single, information-dense sentence that is front-loaded with the core purpose. Each phrase adds value: 'Full test-case card' sets scope, 'text returned as-is (Markdown)' describes return format, and 'Optionally include related executions' covers an option. No waste.
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 simple read-only get-by-id operation with two parameters and no output schema, the description provides sufficient context: what is returned (full card), the format of text, and the optional executions. It does not specify error behavior or pagination, but these are less critical for a get-by-id tool. Overall, it is complete enough for an agent to use effectively.
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 coverage is 100% with descriptions for both 'id' and 'include_executions'. The description adds minimal parameter-specific insight beyond mentioning the optionality of including executions, which is already in the schema. Thus, it meets the baseline but does not exceed it.
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?
The description clearly states the tool's function: retrieving a full test-case card by id ('TestCase.filter by id'). It distinguishes this from sibling tools like kiwi_search_cases by focusing on id-based retrieval and mentions the optional inclusion of related executions, giving a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied (use when you need a full test case by id), but the description does not explicitly state when to use this vs alternatives like kiwi_search_cases or kiwi_update_case. There are no explicit when-not conditions or named alternatives, so it falls short of clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a safe read operation. The description adds that it returns the logged-in user, but little additional behavioral context such as permission requirements or return format.
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?
The description is a single efficient sentence with no filler, front-loading the key information about the tool's purpose.
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 simple, parameterless tool with a readOnly annotation and no output schema, the description adequately conveys its function. It could optionally specify what fields the returned user object contains, but this is not critical.
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?
The tool has zero parameters, and the baseline for 0 params is 4. The phrase 'with no query' reinforces that no arguments are needed, adding slight value beyond the empty input schema.
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?
The description clearly states the tool returns the logged-in user via 'User.filter with no query', using a specific verb and resource. It distinguishes from sibling 'kiwi_list_users' which lists users rather than returning the current one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: this is for getting the current authenticated user, whereas 'kiwi_list_users' is for listing users. However, explicit when-to-use or alternative guidance is not provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return content (attachment metadata and download URLs), adding value beyond the readOnlyHint annotation. It confirms the read-only nature indirectly and gives the agent an expectation of the response shape, though it omits details like whether URLs are temporary or if pagination exists.
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?
The description is a single, concise sentence that front-loads the key information ('TestPlan.list_attachments') and then states the return value. Every word contributes value with no wasted text.
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 simple read-only tool with a single parameter, the description sufficiently conveys the purpose and the return type. The lack of an output schema is mitigated by the mention of 'attachment metadata and download URLs.' It does not discuss any edge cases, but the tool's simplicity makes this acceptable.
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 schema already provides a description for plan_id ('Test plan id'), and the description adds no further parameter semantics. With 100% schema coverage, the description is not required to compensate, so the baseline score of 3 is appropriate.
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?
The description clearly states the action ('list attachments') and the specific resource ('TestPlan'), and it adds the outcome ('Returns attachment metadata and download URLs'). This distinguishes it from sibling tools that list attachments for cases, runs, or executions solely by the resource type mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need attachments for a test plan) but does not explicitly state exclusions or alternatives. Unlike a tool with a named alternative, it relies on the tool name and title to convey the scope, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation covers the safety profile, and the description adds two genuinely non-obvious behavioral facts beyond it: the KIWI_PROJECT default scoping when plan/product are omitted, and the truncated result list with a total count. These affect how an agent interprets results, which the annotation alone does not convey.
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 sentences totaling about 26 words: the first front-loads the core purpose, the second explains default context, the third covers return shape. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description properly covers return values ('total and a truncated list') and the default project behavior that could otherwise surprise an agent. It is adequately complete for an 11-parameter read-only filter tool, though it does not explicitly explain how to page beyond the truncation limit.
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 100%, so the baseline is 3; each parameter's meaning is already fully documented. The description adds a modest cross-parameter semantic (KIWI_PROJECT fallback when plan/product are omitted) but otherwise just compresses the schema's parameter list without new meaning.
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?
The description uses a specific verb+resource construction ('TestCase.filter') and names eight concrete search dimensions (text, plan, status, priority, category, tag, component, automation), making its role as a multi-criteria search tool unmistakable. This clearly distinguishes it from siblings like kiwi_get_case (single-case retrieval) and kiwi_update_case (mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the filter dimension list and the KIWI_PROJECT fallback note, letting an agent infer this is the general case-search tool. However, there is no explicit when-to-use versus alternatives guidance, no exclusion statement (e.g., 'use kiwi_get_case for a known ID'), and no named sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the safety profile. The description adds the scope (all test-case priorities) and the returned data format (id and value with priority levels). It does not mention pagination, ordering, or other behavioral details, but for a simple list this is acceptable.
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?
The description is a single sentence that front-loads the resource and output format. Every word adds value, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema, the description sufficiently covers what it returns and the range of priority values. It provides enough context for an agent to invoke and interpret the result.
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?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 for 0-parameter tools applies, and the description adds no parameter-related information beyond what is in the schema.
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?
The description clearly states the tool lists all test-case priorities, specifies the output fields (id and value), and provides example values (P1..P5 / Critical). This distinguishes it from sibling list tools like kiwi_list_case_statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is given. The description implies the tool is for fetching priority options, but it doesn't name alternatives or exclude other list tools. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already discloses that this is a read-only operation, so the description does not need to repeat that. The description adds minimal behavioral context beyond the schema, such as the 'products/projects' synonym and the optional filter, but no additional details like pagination or sorting behavior.
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?
The description is a single, front-loaded sentence that states the core function and the key optional behavior. Every word is necessary and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional filter and read-only annotation, the description is fully adequate. The tool has no output schema, and the description doesn't need to explain return values given the straightforward nature of a list operation.
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 coverage is 100%, with both 'limit' and 'query' documented. The description's mention of 'optional substring filter' simply mirrors the schema's query parameter description and adds no new semantic information.
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?
The description 'List Kiwi TCMS products/projects' uses a specific verb and clear resource, distinguishing it from sibling tools that list other entities like runs, plans, or builds. The optional substring filter is also mentioned, making the purpose unambiguous.
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 description clearly states when to use this tool for listing products/projects, and the optional filter guides query formulation. It does not explicitly name alternatives, but the resource scope is sufficiently distinct from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds behavioral context by specifying the output is name/value properties and explaining the optional filter scope, which goes beyond the annotation.
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?
Extremely concise at two short sentences. The first sentence 'TestRun.properties.' is slightly redundant as a label, but the overall description is front-loaded and free of waste.
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 simple one-parameter read tool with readOnlyHint, the description adequately conveys purpose, optional filtering, and return value shape. No output schema exists, but the description's 'name/value properties' sufficiently covers expected return content.
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 coverage is 100% with run_id already documented as 'Test run id. Omit to list properties without a run filter.' The description repeats this filter concept but does not add additional meaning beyond the schema, so baseline 3 is appropriate.
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?
Description states it returns name/value properties for a run, with a clear verb ('Returns') and resource ('run properties'). It differentiates from sibling tools by specifying 'run', distinguishing it from case and execution properties tools.
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?
Provides clear context: use to list run properties, and explains the optional run_id behavior ('Omit to list properties without a run filter'). No explicit alternatives or exclusions, but the run-scoped context is sufficient for straightforward selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It reveals important semantics: priority/category accept names, status accepts a name resolved to id or status_id, and text replaces the entire field verbatim with no merging. This goes beyond the schema and warns about destructive text replacement, though it does not cover all mutation side effects.
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?
The description is two tight sentences with no filler. The key behavior is front-loaded ('TestCase.update'), and every clause adds non-redundant detail about field resolution and text semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters and no annotations or output schema, the description covers only the most complex fields (status, priority, category, text). It omits a general note that unspecified fields remain unchanged and does not describe the response shape, validation errors, or permissions. Still, it addresses the riskiest behaviors, making it minimally adequate.
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 coverage is 100%, so the baseline is 3. The description adds meaningful clarification by explaining that status names are resolved to IDs, that priority/category accept names, and that text replacement is verbatim Markdown with no section parsing. This complements the schema rather than repeating it.
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?
The description opens with 'TestCase.update', clearly identifying the action (update) and resource (test case). It differentiates from sibling update tools like kiwi_update_plan and kiwi_update_run by explicitly naming the test-case resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool updates an existing test case but does not explicitly state when to use it versus creating a case or searching for one. No alternative tools or exclusion criteria are mentioned, so the guidance is only implied by the tool's name and required 'id' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is consistent with the 'filter' verb, so no contradiction. The description adds the valuable behavioral detail that KIWI_PROJECT is used as a default when product is omitted, which is not visible in annotations alone. It does not discuss return formatting or pagination, but the schema already covers the limit parameter.
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?
The description consists of two concise sentences that front-load the core purpose ('filter by name, product, type, and active flag') and then provide the default behavior. Every phrase earns its place with no repetition of schema details.
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 simple list/filter tool, the description is largely complete: it names the filters and the default project behavior. No output schema exists, but the tool name 'list_plans' implies a list of plans. It could be improved by explicitly noting that it returns matching test plans, but given the clarity of filters, it is sufficient.
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 schema descriptions cover all five parameters at 100%, so the baseline is 3. The description maps 'name' to the 'query' parameter and adds the KIWI_PROJECT fallback for 'product', which adds some semantic value beyond the schema. However, it does not significantly enhance the other parameters.
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?
The description clearly identifies the tool as a filtering operation on TestPlan with specific attributes: name, product, type, and active flag. This distinguishes it from sibling tools like kiwi_plan_tree which likely return a hierarchical view, while kiwi_list_plans is a flat search.
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 description provides clear context on the tool's scope: it filters test plans by name, product, type, and active status. It also notes the fallback to KIWI_PROJECT when product is omitted, which helps in understanding when the tool will apply a default project. However, it does not explicitly mention when not to use it or direct to an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'any Kiwi TCMS JSON-RPC method' and includes destructive examples like TestPlan.remove_case, which hints at broad capabilities including mutating actions. However, it does not explicitly disclose side effects, permissions, error behavior, or rate limits, leaving the agent to infer these from the API docs link.
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?
The description is two sentences and front-loaded with the core purpose. The first sentence states what the tool does and gives examples; the second provides usage guidance. No unnecessary words.
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 generic JSON-RPC passthrough tool, the description is adequately complete: it provides the API documentation URL, examples, and an explicit use condition. The absence of an output schema means the description need not detail return values. It could mention error handling or authentication, but these are less critical for a generic RPC tool.
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 100%, with both 'method' and 'params' fully documented in the input schema. The description adds no additional parameter-specific details, but the schema already defines the pattern for method names and the flexible params type, so the baseline score of 3 is appropriate.
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?
The description clearly states the tool's purpose: 'Direct call to any Kiwi TCMS JSON-RPC method.' It provides concrete examples (TestPlan.remove_case, TestExecution.add_link, Bug.filter, Tag.filter) and explicitly tells the agent to use this tool when no specialized tool exists, distinguishing it from the many sibling tools.
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?
The phrase 'Use when no specialized tool exists' is explicit guidance for when to select this tool over alternatives. It implies that if a specialized sibling tool (e.g., kiwi_create_run, kiwi_get_case) is available, this general-purpose RPC tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds behavioral details about returning URL, configured Product, and product count, as well as checking credentials, offering useful context beyond the annotation without contradicting it.
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?
The description is two short sentences, front-loaded with the verb 'Checks,' and every clause adds value: what it does, what it returns, and when to use it. No redundant or generic filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only diagnostic tool, the description is fully adequate. It covers purpose, output, and usage context, and no output schema exists to add further detail. The description stands on its own.
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?
The input schema has zero parameters, so there is nothing to document. Per the rubric, a zero-parameter tool gets a baseline of 4, and the description appropriately does not spend space on parameters.
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?
The description clearly states 'Checks connectivity and credentials' and 'Use for diagnostics,' making the tool's purpose specific and distinct from the many sibling CRUD tools. It also mentions the output (URL, Product, product count), further clarifying its role.
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 description provides clear context by saying 'Use for diagnostics,' which tells the agent when to invoke this tool. However, it does not explicitly mention alternatives or when not to use it, though no sibling tool serves a similar diagnostic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures several valuable behaviors beyond the annotations: category/priority names are resolved to ids, setting plan triggers TestPlan.add_case, tags are added one by one, and text is stored verbatim with no section parsing. Annotations only provide destructiveHint=false, so this context is essential.
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?
Every sentence carries dense, non-redundant information. The description front-loads the core action and then adds behavioral details in logical order, with no filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-param create tool with no output schema, the description covers major behavioral nuances including defaults, name resolution, attachment, tags, and text format. Remaining params are left to the schema, which already documents them adequately.
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 covers all 13 params, but the description enriches key ones: product default, category/priority name-to-id resolution, plan attachment semantics, comma-separated tags being added individually, and Markdown text behavior. It goes beyond schema descriptions, though not every parameter is addressed.
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?
Description opens with 'TestCase.create in the product', clearly identifying the action (create) and resource (test case) while scoping to Kiwi. The verb and resource distinguish it from update, plan, and run tools in the sibling list.
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?
Provides clear context: defaults to KIWI_PROJECT, category/priority name resolution, and plan attachment behavior. However, it does not explicitly name alternatives or state when not to use it, such as preferring kiwi_plan_add_case for existing cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kiwi-tcms-mcp MCP server](https://glama.ai/mcp/servers/belovdm/kiwi-tcms-mcp/badges/card.svg)](https://glama.ai/mcp/servers/belovdm/kiwi-tcms-mcp)

Score Badge

Copy to your README.md:

[![kiwi-tcms-mcp MCP server](https://glama.ai/mcp/servers/belovdm/kiwi-tcms-mcp/badges/score.svg)](https://glama.ai/mcp/servers/belovdm/kiwi-tcms-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/belovdm/kiwi-tcms-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server