Find specific test runs by filtering on plan, product, summary text, or open status to quickly locate relevant execution records.
Search test runs. query common keys: {"plan": <plan_id>}, {"build__version__product": <product_id>}, {"summary__icontains": "trip"}, {"stop_date__isnull": true} (still open).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. 'Search test runs' clearly indicates a non-destructive read, and the '(still open)' note clarifies the stop_date filter semantics. It does not disclose return format, pagination, or whether an empty query returns all runs, so behavior is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence states the operation, then immediately gives compact code examples. Every part earns its place, and no redundant wording is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with no output schema and no annotations, the common-key examples provide the core invocation knowledge an agent needs. Missing details include whether query is optional, what an empty search returns, and response shape or pagination; these gaps prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only defines query as an unconstrained object, so the description compensates well by listing common JSON keys and example value types. It gives enough concrete syntax to construct a valid filter object, though it does not enumerate all possible keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific verb 'Search' and the resource 'test runs,' making the tool's function immediately clear among siblings like kiwi_get_test_executions or kiwi_get_run_cases. It stops short of explicitly contrasting it with those siblings, so it doesn't quite earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete query patterns (plan, product, summary icontains, still-open runs), which conveys how to use the tool and implies it should be used for searching test runs. However, there is no explicit guidance about when to prefer this over sibling tools such as kiwi_get_test_executions or kiwi_get_run_cases, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.